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

minion-army should handle errors in a more flexible way #162

Open
nissimlavy-pager opened this issue Apr 29, 2020 · 1 comment
Open

minion-army should handle errors in a more flexible way #162

nissimlavy-pager opened this issue Apr 29, 2020 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@nissimlavy-pager
Copy link

Currently, we only have the option to treat all errors equally, which is not always what we want to be doing.

For example, in the event that we get a bad message that causes validation to throw an error, we might want to quietly handle that with logging something and moving on. But in that case, we end up swallowing all errors and just logging them.

Current army behavior should be opt-in, but a "safer" default should be applied to most apps, eg:

  • bad payload is dropped in queue, fails validation
  • check Army config, if dlx is set, nack and move message there, flag with a warn or lower trace
  • if no dlx is configured, ack by default and silently discard the message, log the error with warn or lower trace
  • keep processing backlog
    doesn't block, app doesn't fail on userland error, errors on army that throw will crash the app as expected etc
    if apps opt-into the existing behavior, then devs do so in a more deliberate way, knowing there will be outages and backlog delays
@cilindrox cilindrox added enhancement New feature or request help wanted Extra attention is needed labels Apr 29, 2020
@cilindrox
Copy link

Thanks @nissimlavy-pager

Adding to this - there seems to be side effects to not registering an error listener - causing the app to crash (expected NodeJS behavior) but failing to complete the nack call (unexpected side effect).
Ideally, we want any errors to call the nack handler, and then bubble up any exceptions throughout the stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants