> this is merely an error trace, so it should just be called that It's stricter than an error trace because if it's encountered in a development/testing contex

> this is merely an error trace, so it should just be called that It's stricter than an error trace because if it's encountered in a development/testing context, it's a hard error and the engineer must fix it to proceed. Plain error traces should only be used for expected failure scenarios (like a third-party service times out, possibly), not situations that would be considered "unexpected" to the developer.