What are the Slack Archives?
Itβs a history of our time together in the Slack Community! Thereβs a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.
Because this space is not active, you wonβt be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..
is there a place in documentation which describes good practices when it comes to error handling and
is there a place in documentation which describes good practices when it comes to error handling and reporting inside event listeners?
I'm asking this question because I have event listener which sends requests to an external API and would like to know what to do if API returns error response
Comments
-
I don't know if there's a general documentation for this behavior, but I'd stick to the Spryker defaults.
This means: If anything goes wrong, throw an Exception with a usable error message and it's automatically dead-lettered to the *.error queue. That way, you can monitor the *.error queues and shovel the messages back and forth if need be.0 -
thanks, this helped
0 -
do you know if this behavior is described somewhere?
0 -
No idea, but this is effectively how it works.
0 -
I wonder how this affects other listeners that might also be handling that events
0 -
and other events if I am using bulk handler
0 -
My best guess is that the processing is aborted and the message gets moved right away by the MessageProcessor.
0 -
Your event handlers should - in the best case - be idempotent (aka functional, stateless) so that they can be triggered anytime.
0 -
The only thing I was able to find in documentation is
*Error Handling*. Plan for error handling during message processing such as routing to another queue, re-queuing, etc.
throwing an Exception and thus sending the message into the β*.errorβ queue is a default approach, however you can build a another message and send it to the custom queue for further processing and ack the original one, if you donβt want to interrupt further listeners
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 75 Spryker News
- 924 Developer Corner
- 783 Spryker Development
- 88 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 35 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 25 Job Opportunities
- 3.2K π Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 70 Spryker Safari Questions
- 50 Random