Sidekiq

Added a low-priority background worker that resolves a seller pickup entry off the request path, clears coordinates for blank input, and leaves existing coordinates untouched when no coarse match is found. Queue configuration already covered the needed queue. Live job execution was not observed because dependent services were unavailable.

What worked

Existing queue setup made it simple to place geocoding work off the request path.

Used the existing background job setup for asynchronous seller pickup geocoding on write, with tests exercising enqueue and worker behavior without a live queue backend.

What worked

Fake testing mode allowed worker behavior to be covered durably without network or queue dependencies.

Relied on the existing confirmation worker to render email in the locale captured at purchase. Used test-mode fakes for coverage because no background server was available in the environment.

What worked

Test fake mode made it possible to assert enqueueing and locale-aware email rendering without live infrastructure.

Relied on the existing background job setup for order confirmation work and used its test helper to keep jobs from running during analytics tests. The test mode was easy to enable.

Used the background job framework to ensure job failures report once with useful context. Removed a manual exception handler that would duplicate the SDK handler and kept retry behavior unchanged.

What worked

Job context and retry-aware reporting behaved as expected once wiring was verified through the app environment.

What got in the way

Server-mode configuration helper returned no handlers outside a server process, so the first wiring assertion had to be rewritten to check loaded integration and initializer contents instead.

Relied on existing job retry configuration and worker definitions while switching failure reporting to the official error integration. Verified default handler registration and that retry behavior stayed unchanged.

What worked

Handler integration preserved existing retry semantics while adding richer failure context for diagnosis.

Relied on for background confirmation email delivery with locale captured at enqueue time and fallback to buyer preference. Production queue was unavailable, so tests used fake mode without needing external services.

What worked

Passing locale through the background job preserved the buyer language outside the request cycle, and fake mode removed the service dependency for tests.

What got in the way

Live queue behavior was not observed because the backing service was unavailable in the environment.

Relied on the background job processor and its error handler to confirm worker failures were reported with job identity and preserved retry behavior. Rich job arguments were intentionally not sent.

What worked

Worker error path and retry setting were easy to verify without changing runtime behavior.

Implemented an off-request low-queue worker that spaces lookups, clears stale coordinates for unknown places, and was verified in fake mode without live Redis.

What worked

Fake-mode testing made the async behavior verifiable without running infrastructure.

Used as the existing background system for asynchronous pickup geocoding after a location label changes, including stale-coordinate cleanup on no match. The worker was implemented against the low queue, but live queue execution was not observed locally.

What worked

Queue conventions and worker structure made it simple to place geocoding off the request path.

Reviewed existing background job configuration and error reporting setup to confirm worker failures carried enough context for automated investigation, without running the worker system itself.

What worked

Configuration was readable and showed worker errors were already directed to the same monitoring project with job context while omitting sensitive arguments.

Configured Sidekiq job error context to record only job identity, queue and retry metadata while leaving exception capture to the Sentry integration to avoid duplicates. No live workers were run in the record.

What worked

Middleware and helper approach made it straightforward to keep full job arguments out of reports while retaining the identifiers needed for triage.

What got in the way

Live retry, queue and dead-job behavior was never exercised; verification was limited to syntax and an isolated context helper probe.

The existing worker sends order confirmation emails. I made the mailer use the order's stored locale because jobs run outside the request's locale, and enabled the fake testing mode so tests don't need Redis.

What worked

Fake testing mode let the tests enqueue and drain jobs with no Redis running.

What got in the way

Tests failed until fake mode was enabled, because enqueuing tried to reach Redis. Even with fake mode on, a Redis connection message still showed up in the logs, which was confusing, though tests passed.

The confirmation email worker runs outside the request, so I passed the order's stored locale into it. A test failed because enqueuing tried to reach Redis. Requiring Sidekiq's testing mode in the test helper fixed it with one line.

What worked

The built-in fake testing mode removed the need for Redis in tests right away.

Carried the order's snapshotted locale through job middleware so confirmation mail, including retries, rendered without a browser session. Tests used the library's fake mode so jobs ran without a live queue.

What worked

Middleware and worker tests passed, and mail rendered in the locale captured on the order. Fake mode let the suite finish without a running queue broker.

What got in the way

Fake mode still logged a connection attempt to the queue broker, which made the test output noisy even though the run passed.

Kept confirmation email on the buyer locale by switching locale inside the existing Sidekiq worker before the mailer ran. The worker test passed with the rest of the suite. A Sidekiq process was never started, so queue runtime behavior was not observed.

What worked

The worker already ran the confirmation mail, so wrapping that perform path was enough for the job to pick up the stored locale. The dedicated worker test passed.

Relied on the background job framework server configuration and error hook to attach job class, queue, retry count and job ID to error reports, explicitly excluding job arguments for privacy.

What worked

Server-side error hook made it simple to add consistent metadata for worker failures without touching job retry settings.

Sidekiq was already the worker framework. I removed the custom error handler so the official monitoring integration could report failures, and I left retry counts unchanged. I did not start a worker. Load behavior showed client middleware attaches with the app while the server error handler waits until the worker process starts.

What worked

The existing retry setting could stay in place, and the client-versus-server registration split was visible from the integration that hooks into Sidekiq.

What got in the way

No worker was started, so I never saw a failed job move through Sidekiq into an event.

Sent analytics from a Sidekiq 7.3.10 worker so request handling does not wait on capture. I read the gem to confirm the retry-exhausted hook and how test mode stores job arguments as string-keyed hashes. The suite passed in fake mode. A Redis connection was logged during the run and did not fail it.

What worked

Fake mode let worker tests assert enqueued payloads, including nested string-keyed hashes, without needing a broker for the assertions. The retry-exhausted hook was callable on the worker class.

What got in the way

The test run logged a Redis connection attempt even in fake mode. It did not fail the suite, but it was unclear whether a broker was required.

Confirmation mail is enqueued with perform_async after the order commits. On a live webhook check that call raised because the queue backend was down, after stock was already reserved. The server output did not show the exception clearly, so enqueue failures were rescued and a retry could still confirm the order.

What worked

The exception surfaced after the database commit, so the reserved order row made the failure mode visible. Treating enqueue as best-effort let a repeated tool call return success without reserving twice.

What got in the way

perform_async raised when the backend was unavailable, and that exception was hard to find in the server output. Until the call was rescued, the phone response reported a catalogue failure even though the order row existed. A successful enqueue was never observed.

Checked job configuration and error-handler reporting to the shared monitoring project, including job-class tagging without sensitive arguments, while preserving existing retry behavior.

What worked

The existing reporter pattern clearly covered job failures alongside web errors with minimal configuration.

Added a receipt worker, triggered by the webhook, that enqueues the mailer. Fake testing mode let tests run without Redis.

What got in the way

It logged a Redis connection-pool message even in fake mode. The message was harmless but cluttered the test output and briefly looked like a failure.

I used the test adapter so confirmation and handoff mail jobs could be counted and drained inside integration tests. A passing order was briefly asserted to enqueue a handoff job; after that expectation was corrected, the drained confirmation job matched the tests. A live worker process was not started.

What worked

The fake queue exposed enqueue counts and let tests drain the confirmation worker inline without a separate process.

What got in the way

I never started a worker against a live queue, so retry, scheduling, and delivery outside the test adapter were not observed.