feat: add per-task types_of_exceptions#651
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #651 +/- ##
==========================================
+ Coverage 81.29% 81.48% +0.19%
==========================================
Files 69 69
Lines 2577 2593 +16
==========================================
+ Hits 2095 2113 +18
+ Misses 482 480 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Can you please test out what happens when you send a task with a tuple of exceptions in labels using some distributed brokers? I wonder what type will it end up with? |
| :param message: Original task message. | ||
| :return: Effective exception types or None. | ||
| """ | ||
| task = self.broker.find_task(message.task_name) |
There was a problem hiding this comment.
A regular label belongs to a specific message. It is produced by the producer, passed through the broker, and can be overridden via .kicker().with_labels(...).
In contrast, types_of_exceptions is effectively part of the task definition on the worker side. The value passed with the message is not used for any decision-making.
It seems to me that this results in the task labels being silently lost before the retry.
The same issue exists in simple_retry_middleware.py:44
3 participants
No description provided.