feat: capture controller reconciliation errors to Sentry/GlitchTip #14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/controller-sentry-errors"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add captureError calls throughout the RunnerPool controller for all
error paths: build_forgejo_client, get_registration_token,
reconcile_registration_secret, build/create/get/update deployment,
build_configmap, reconcile_configmap, create_remote_backend, list_vms.
Each error includes pool name and step tags.
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
Automated review by pr-reviewer v0.15.0 | Safety Check | anthropic | tracking id
r-c5a136-88d4a9This is an AI-generated review and may contain mistakes.
Status: ✅ Completed
✅ Verdict: LGTM — The changes add error reporting to Sentry/GlitchTip throughout the controller with proper scoping and no obvious security or logic issues.
Complexity: moderate
Safety Check Review
This PR adds Sentry error capture throughout the RunnerPool controller reconciliation process. The changes are straightforward and safe:
✅ Error handling: All
captureErrorcalls are added to existing error paths without changing the control flow✅ Scoping: The
captureErrorfunction properly uses Sentry scopes with pool and step tags✅ Null safety: Checks if Sentry client is configured before attempting to capture errors
✅ Status updates: New
setErrorStatusmethod appropriately updates pool status and metrics on errorsNo security vulnerabilities, breaking changes, or obvious bugs detected. The Sentry integration is properly implemented with defensive programming practices.