feat(webapp): trace deployment outcomes and compute template creation#4015
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 (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
WalkthroughTwo separate observability improvements are added. First, a new 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
dc84dc5 to
ff69578
Compare
…r-fail; drop unused CANCELED)
Deploy success/failure wasn't easily observable: compute template creation only logged, and the terminal deployment statuses (deployed / failed / timed-out) weren't traced — so deploy health couldn't be seen without querying the database.
This adds two spans:
compute.template.createaround template creation at finalize, tagging the resolved mode and per-preset outcome.resolveModenow returns its decision (mode + reason) so the span can record why a mode was chosen.deployment.outcomevia a small shared helper (recordDeploymentOutcome) emitted at every terminal-status write — finalize (deployed), fail / index-failed / background-worker (failed), and timeout (timed out) — so deploy success/failure is queryable by status and reason.The helper is best-effort (org/project/env enrichment where cheaply available) and never throws, so telemetry can't break a deploy.