feat(workflow-engine-app): propagate HTTP status code in AppCommand error results - #19958
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review. 📝 WalkthroughWalkthroughAppCommand callback failures now include HTTP status codes in ChangesAppCommand status propagation
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The change records HTTP status codes for classified AppCommand callback failures while preserving existing messages and non-HTTP behavior; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
4b3fa74 to
75a3842
Compare
…rror results Makes app-callback error history machine-readable: the response status code now lands in ErrorEntry.HttpStatusCode instead of only the message string, matching WebhookCommand. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
75a3842 to
b819601
Compare
Description
AppCommandnow passes the callback response's status code intoExecutionResult.CriticalError/RetryableError, giving app-callback error history parity withWebhookCommand: every persistedErrorEntrycarries a machine-readableHttpStatusCodeinstead of embedding it only in the message text.httpStatusCode; message strings are unchanged.Second prerequisite of the failure-storm throttling design (#18481), whose detection refinements group failures by status code; stacked on #19957 (and the ADR in #19954).
Verification
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests