Skip to content

Add stack trace to error handler's HandlePanicFunc - #423

Merged
brandur merged 1 commit into
masterfrom
brandur-panic-trace
Jul 4, 2024
Merged

Add stack trace to error handler's HandlePanicFunc#423
brandur merged 1 commit into
masterfrom
brandur-panic-trace

Conversation

@brandur

@brandur brandur commented Jul 4, 2024

Copy link
Copy Markdown
Contributor

This one in response to #418 in which although we persist a stack trace
to a job row's errors property, we don't reveal it in a panic handler,
which is quite inconvenient for purposes of logging or other telemetry
(e.g. sending to Sentry).

Here, HandlePanic's signature changes to (trace is added):

HandlePanic(ctx context.Context, job *rivertype.JobRow, panicVal any, trace string) *ErrorHandlerResult

A couple notes on choices:

  • The naming of trace is reused from AttemptError.

  • The value type is string. This is a little non-obvious because Go
    exposes it as a []byte, something I've never quite understood as to
    why, but I did string because for one it's more convenient to use,
    but more importantly, it's the same type on AttemptError.

This is a breaking change, but it seems like being able to get a stack
trace during panic is important enough that it's worth it, and with any
luck there's few enough people using this feature that it won't break
that many people. The fix is quite easy regardless and will easily be
caught by the compiler.

Fixes #418.

@brandur
brandur requested a review from bgentry July 4, 2024 05:35
@brandur
brandur force-pushed the brandur-panic-trace branch from 3a5c57b to fabdde1 Compare July 4, 2024 05:40

@bgentry bgentry left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM aside from comments. Thanks for jumping on this!

Comment thread CHANGELOG.md Outdated

### Changed

⚠️ Version 0.8.0 has a small breaking change in `ErrorHandler`. As before, we try never to make breaking changes, but this one was deemed quite important because `ErrorHandler` was fundamentally lacking important functionality.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong version number?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, thanks. Fixed.

Comment thread job_executor.go Outdated
case res.PanicVal != nil:
errorHandlerRes = invokeAndHandlePanic("HandlePanic", func() *ErrorHandlerResult {
return e.ErrorHandler.HandlePanic(ctx, e.JobRow, res.PanicVal)
return e.ErrorHandler.HandlePanic(ctx, e.JobRow, res.PanicVal, string(res.PanicTrace))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we convert this to string once when saving it to the result so that it doesn’t have to be cast here and by pgx when writing to the db?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, makes sense. Fixed.

This one in response to #418 in which although we persist a stack trace
to a job row's errors property, we don't reveal it in a panic handler,
which is quite inconvenient for purposes of logging or other telemetry
(e.g. sending to Sentry).

Here, `HandlePanic`'s signature changes to (`trace` is added):

    HandlePanic(ctx context.Context, job *rivertype.JobRow, panicVal any, trace string) *ErrorHandlerResult

A couple notes on choices:

* The naming of `trace` is reused from `AttemptError`.

* The value type is `string`. This is a little non-obvious because Go
  exposes it as a `[]byte`, something I've never quite understood as to
  why, but I did `string` because for one it's more convenient to use,
  but more importantly, it's the same type on `AttemptError`.

This is a breaking change, but it seems like being able to get a stack
trace during panic is important enough that it's worth it, and with any
luck there's few enough people using this feature that it won't break
that many people. The fix is quite easy regardless and will easily be
caught by the compiler.

Fixes #418.
@brandur
brandur force-pushed the brandur-panic-trace branch from fabdde1 to aeb3b97 Compare July 4, 2024 14:26
@brandur
brandur merged commit 7899e20 into master Jul 4, 2024
@brandur
brandur deleted the brandur-panic-trace branch July 4, 2024 14:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

river hides panic stack traces in database

2 participants