Wire Bugsnag into the API server

[morgan-wowk]

TL;DR

Integrates Bugsnag error monitoring into the API server.

What changed?

• Bugsnag is initialized during app startup with the service name tangle-api.
• The BugsnagMiddleware is conditionally added to the FastAPI middleware stack when Bugsnag is enabled.
• Unhandled exceptions caught by the global exception handler are now reported to Bugsnag via bugsnag_instrumentation.notify.

How to test?

• Enable Bugsnag by configuring the appropriate environment variables/credentials.
• Trigger an unhandled exception in the API and verify it appears in the Bugsnag dashboard.
• Confirm the middleware is only added when IS_BUGSNAG_ENABLED is True, and that the app starts normally when Bugsnag is disabled.

Why make this change?

To improve observability and error tracking in production by capturing and reporting unhandled exceptions to Bugsnag, enabling faster diagnosis and resolution of issues.

Bugsnag ASGI Middleware

BugsnagMiddleware (source) wraps the ASGI layer and automatically enriches every error event with request context:

• Client IP from the ASGI scope
• HTTP method, version, and path
• Full request URL (scheme + host + port + path + query string)
• All request headers — with authorization, cookie, x-api-key, and proxy-authorization redacted via params_filters
• ASGI scope dict as an "environment" tab — opt-in via send_environment=True, off by default

The middleware and the explicit bugsnag.notify() call in handle_error are complementary, not duplicative: FastAPI's exception handler consumes exceptions before they reach the ASGI layer, so handle_error covers normal request errors while BugsnagMiddleware acts as a safety net for exceptions that escape FastAPI entirely (e.g. startup failures, middleware crashes).

Additionally, every Bugsnag event — whether from the middleware or from a direct notify() call — is enriched with a "tangle_context" tab via our before_notify callback, containing: request_id, user_id, pipeline_run_id, and execution_id from the current request context.

[morgan-wowk]

• Add Bugsnag error grouping with stable normalized keys #234
• Wire Bugsnag into the orchestrator #232
• Wire Bugsnag into the API server #231 👈 (View in Graphite)
• Add Bugsnag instrumentation module #230
• Add bugsnag Python SDK dependency #229
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[yuechao-qin]

Sorry for the noise, I realize you mention this is not ready for review yet, but wanted to add this comment before I forget.

I really like how you added in the orchestrator stack for adding the execution.id to the exception for better tracebility. Not sure if there is anything like that now in the API level? I believe we are adding system level annotations to the source (UI, CLI/tangle-deploy), that "might" be nice to add to this to label the exception better.

Just a thought, if we don't have the plumbing now to easily do this, then not a concern.

[morgan-wowk]

It is welcome. Good question / topic to look into!

[morgan-wowk]

You're correct. We don't have any traces or contextual ids in the API level.

+1 that having the source would be great!

[morgan-wowk]

I'll defer adding that to a future PR since the source has been in discussion recently and may change

[morgan-wowk]

Merge activity

• May 15, 5:05 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 15, 5:08 PM UTC: Graphite rebased this pull request as part of a merge.
• May 15, 5:09 PM UTC: @morgan-wowk merged this pull request with Graphite.