Repository navigation
Log Sidekiq and Puma errors with typed fields, and an ActiveJob job's Sidekiq error unless ActiveJob logged it - #22
Merged
Merged
Conversation
The TypeScript generator mapped T.class_of(StandardError) to string but not T.class_of(Exception), the type Log::Error's error_class has now, so the generated error_class became `any`.
Sidekiq's job error line and Puma's request error line put their fields (Sidekiq's context, the job ID and class, queue and retry count; Puma's context, method and path) in additional_data, which is only for fields LogStruct doesn't know about. They're new events with schema fields now: Log::Sidekiq::Error and Log::Puma::Error, with a new error_context field for what Sidekiq or Puma was doing. Log::Sidekiq becomes Log::Sidekiq::Log. The Sidekiq error line has the job's ID and class in ctx, like the lines logged while the job ran, so a query on ctx.jid finds the error too. Sidekiq calls its error handlers after the job's middleware has finished, so the line is logged with the same tags. Puma's request errors that aren't StandardErrors are logged too.
Sidekiq's error handler skipped every ActiveJob job's error, leaving it to the ActiveJob integration. An error raised before ActiveJob ran the job, such as the NameError for a job class a deploy removed, was then in no log line. The handler now skips only the errors the ActiveJob integration logged (LogStruct::LoggedErrors), as the GoodJob integration does.
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 18
✨ Finishing Touches
Comment |
This was referenced Oct 17, 2026
Merged
ndbroadbent
changed the base branch from
nathan/mailer-error-handling
to
main
October 18, 2026 00:39
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.
Seventh of twelve stacked PRs for 0.2.0.
What this fixes
job's error and left it to the ActiveJob integration, so the
NameErrorfor a job class a deploy removed (raisedwhile Sidekiq deserializes the job) wasn't logged anywhere. The handler now skips only the errors the ActiveJob
integration logged (
LogStruct::LoggedErrors), as the GoodJob integration does.retry count; Puma's context, method and path) were in
additional_data, which is for fields LogStruct doesn't know.They're new events with schema fields:
Log::Sidekiq::ErrorandLog::Puma::Error, with anerror_contextfieldfor what Sidekiq or Puma was doing. Breaking:
Log::Sidekiqis nowLog::Sidekiq::Log.jidand class inctx, like the lines logged while the job ran, so a queryon
ctx.jidfinds the error too.StandardErrors are logged too.error_classas a string. It wasanyonceLog::Error'serror_classbecameT.class_of(Exception).Testing
New tests for each change. Sorbet and the unit suite (310 tests) pass at this branch's tip.
Stack for 0.2.0, merged in order: #16 → #17 → #18 → #19 → #20 → #21 → #22 → #23 → #24 → #25 → #26 → #27