Module: RailsErrorDashboard::Concerns::LocalizedJob

Extended by:

ActiveSupport::Concern

Included in:

ApplicationJob

Defined in:

app/jobs/rails_error_dashboard/concerns/localized_job.rb

Overview

Gives a job an explicit, serialized locale instead of an inherited one.

WHY JOBS CANNOT JUST READ Current.locale

Mailers and notification jobs render outside the dashboard's around_action. There is no request, so there is no request locale. Reading Current.locale in a job returns nil at best — and at worst, on a reused Puma or job-runner thread, whatever an unrelated request left behind. That is the same bug class as #143 and #148: state outliving the request that set it.

So the locale is resolved at ENQUEUE time (see .enqueue_locale) and travels in the job's arguments. The job then reads only its own argument.

WHY ENQUEUE TIME RESOLVES TO CONFIG, NOT TO A USER

Notifications are enqueued from the capture path — log_error, the storm gate — which runs inside a host app request, not a dashboard one. There is no dashboard user in scope and Current.locale is correctly nil there. The meaningful answer is config.dashboard_locale, which is what Current.locale_or_default returns when Current.locale is unset. Resolving through that one path keeps a single precedence chain for the whole gem and lets a dashboard-initiated enqueue (a future "send test notification" button) pick up the acting user's locale for free.

BACKWARD COMPATIBILITY IS NOT OPTIONAL HERE

Queues drain across a deploy. Jobs enqueued by the previous version have no locale argument at all, and they must still run — a notification is never worth losing over a translation detail. Every consumer therefore defaults the argument, and #job_locale hardens whatever arrives.