You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Steno currently panics when the consumer does certain things that violate our constraints. This includes things like looking up an output for a node that your node doesn't depend on. These are programmer errors, but they can be safely handled while still producing adequate debugging information.
It seems easy to have these happen in practice (by copying/pasting the wrong thing). It's really bad when sagas panic (since they will be recovered and panic again). Consumers already have to propagate operational errors that they can't directly handle (e.g., failure to deserialize an output from a previous node). Given all this, we may as well turn this particular example into a handled operational error. We should audit other uses of unwrap(), panic!(), and expect() for situations like this.
I'm not saying we shouldn't ever panic in Steno. But we may want to limit this to internal invariant violations, not incorrect usage.
The text was updated successfully, but these errors were encountered:
After #29, there are a few other cases that we'll validate at DAG construction time, but we should validate again during recovery so that we don't panic later (or else produce operational errors later if we find these invariants violated):
a subsaga node's parameters come from a node that it doesn't depend on (or that's missing altogether)
a DAG ends in any number of nodes other than 1
One way to do some of this would be to have a special ActionError type similar to ActionConstant that produces a specific error. If we run into a problem satisfying expected preconditions for a node, we can replace its action with that.
Steno currently panics when the consumer does certain things that violate our constraints. This includes things like looking up an output for a node that your node doesn't depend on. These are programmer errors, but they can be safely handled while still producing adequate debugging information.
It seems easy to have these happen in practice (by copying/pasting the wrong thing). It's really bad when sagas panic (since they will be recovered and panic again). Consumers already have to propagate operational errors that they can't directly handle (e.g., failure to deserialize an output from a previous node). Given all this, we may as well turn this particular example into a handled operational error. We should audit other uses of
unwrap()
,panic!()
, andexpect()
for situations like this.I'm not saying we shouldn't ever panic in Steno. But we may want to limit this to internal invariant violations, not incorrect usage.
The text was updated successfully, but these errors were encountered: