fix(sentry): pass the Throwable so workflow-generation failures are diagnosable - #135
Merged
Merged
Conversation
…iagnosable Sentry #1035 arrived as a bare message: no exception class, no stacktrace, no context. sentry-laravel promotes `context['exception']` to captureException(); passing only `$e->getMessage()` yields captureMessage() instead. Verified by contrast in the same app: OidcSocialController already passes the Throwable and its issue (#1030) is the only one of the four with a stacktrace.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the fleetq unresolved-issue sweep. Addresses Sentry #1035 (
GenerateWorkflowFromPromptAction: LLM call failed).Problem
The issue arrived at Sentry as a bare message — no exception class, no stacktrace, no application context. Verified against the raw event JSON:
contextheld onlymonolog.channel/monolog.level, and there was nolog_context, noerror, no ids.Cause: the catch block logged
'error' => $e->getMessage()— a string.sentry-laravel's handler promotescontext['exception']tocaptureException()(class + stacktrace + grouping) and otherwise falls back tocaptureMessage():Confirmed by contrast rather than assumption: of the four unresolved fleetq issues, only #1030 has a stacktrace — and
OidcSocialControlleris the only one of the four call sites that already passes'exception' => $e. The other three pass a message string and all three are stacktrace-less.Change
One key added to the existing context array. No behaviour change, no new branching.
Scope note
This makes the next occurrence diagnosable; it does not root-cause the LLM failure, because the events Sentry holds today contain nothing to root-cause from. Stating that plainly rather than claiming a fix.
The cloud-layer siblings (#824
BaseStageJob, #847ProcessAssistantMessageJob) live inoverrides/in the private repo and are fixed there — their base counterparts already callSentryEventCapturerwith the Throwable, so community edition was never affected.Tests
The equivalent assertion (Throwable reaches the log context) is covered on the OIDC path in the private repo — 14 passed there. This action has no existing test harness and mocking the gateway for a one-key context addition would be scaffolding for its own sake, so it ships untested; pint + phpstan clean.