fix: use default retry settings when no catchError handlers are defined#1852
fix: use default retry settings when no catchError handlers are defined#1852matt-aitken merged 1 commit intomainfrom
Conversation
|
WalkthroughThis update refines database querying, error handling, and retry logic. In the webapp service, a select clause now limits database output to four specific fields. In the core worker module, a new constant centralizes retry logic in error handling, and the corresponding test has been updated to support additional retry configuration. Furthermore, a new file introduces a task with exponential backoff retry behavior, simulating failures until a configured condition is met. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant RetryTask
Client->>RetryTask: run(payload with failCount)
loop Retry Attempts (while current attempt <= failCount)
RetryTask->>RetryTask: Log current attempt
alt Attempt still failing
RetryTask->>RetryTask: Throw error & Log warning
end
end
RetryTask->>Client: Return result with number of attempts
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (4)
⏰ Context from checks skipped due to timeout of 90000ms (5)
🔇 Additional comments (8)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Summary by CodeRabbit