fix(webapp): log transient Attio 5xx/429 at warn instead of error#4270
Conversation
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details⏰ Context from checks skipped due to timeout. (4)
WalkthroughUpdated Attio response handling to classify HTTP 5xx and 429 responses as transient, log them as warnings, and tag thrown errors with 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 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 |
Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>
The signup → Attio sync (
attio.server.ts#assert) logged every non-2xx response aterrorlevel and threw the same way regardless of status. Transient upstream failures (5xx/429) are retried by the common worker and self-heal, so treating them as errors created false alerts for something that isn't actually a bug.Now
#assertsplits the two cases:warnand thrown withlogLevel: "warn", so they continue to be retried but don't raise error-level alerts. This reuses the same pattern the worker already honors (directorySyncEffects).errorand thrown, so genuine integration bugs (schema, permissions, auth, etc.) remain visible.There is no behavior change to retries or the signup flow. This is a server-only change.