Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

steno panics too much on consumers' mistakes #32

Open
davepacheco opened this issue Jul 28, 2022 · 1 comment
Open

steno panics too much on consumers' mistakes #32

davepacheco opened this issue Jul 28, 2022 · 1 comment

Comments

@davepacheco
Copy link
Collaborator

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.

@davepacheco
Copy link
Collaborator Author

davepacheco commented Jul 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant