[codex] Queue translation cache refreshes

[riderx]

Summary

• move translation cache generation out of request waitUntil work and into a Cloudflare Queue consumer
• enqueue cold-cache and stale-cache refresh jobs while continuing to redirect cold misses to English and serve stale cached pages
• add queue producer/consumer bindings plus deploy workflow queue creation

Validation

• bun run ci:verify:translation
• bunx prettier --check apps/translation-worker/src/index.ts apps/translation-worker/wrangler.jsonc .github/workflows/deploy-translation.yml
• cd apps/translation-worker && bunx wrangler deploy --dry-run

Summary by CodeRabbit

• New Features

  • Implemented queue-based translation refresh workflow for improved reliability and performance of concurrent translation requests.

• Chores

  • Updated deployment pipeline configuration and processes for message queue integration.

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request introduces a queue-based architecture for managing translation cache refreshes in the Cloudflare worker. Previously, cache refreshes were triggered inline during requests. Now, translation jobs are enqueued for asynchronous processing by a dedicated queue consumer, with a pre-deploy CI step ensuring the required Cloudflare queue exists.

Changes

Cohort / File(s)	Summary
CI/Configuration .github/workflows/deploy-translation.yml, apps/translation-worker/wrangler.jsonc	Adds pre-deploy step to create Cloudflare queue capgo-translation-refresh with idempotent error handling. Configures queue producer/consumer bindings with batching disabled, 3 retries, 60s retry delay, and max concurrency of 2 for both production and development environments.
Worker Implementation apps/translation-worker/src/index.ts	Refactors cache refresh mechanism from inline request handling to queue-driven workflow. Removes ExecutionContext parameter from fetch handler and adds new queue handler for processing TranslationJob messages. Introduces queue data types, pending-marker cache keys, and sequential job validation/processing with error handling on batch failures.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Worker as Translation Worker
    participant Queue as Cloudflare Queue
    participant Cache as Cloudflare KV Cache
    
    Client->>Worker: HTTP Request for translation
    alt Cache miss or stale entry
        Worker->>Worker: Record pending marker in cache
        Worker->>Queue: Enqueue TranslationJob
        Worker-->>Client: Return response
    end
    
    Queue->>Worker: Invoke queue handler with batch
    activate Worker
        Worker->>Worker: Validate cacheVersion & locale
        Worker->>Cache: Fetch & render translated HTML
        Worker->>Cache: Update cache with translation
        Worker->>Cache: Clear pending marker
    deactivate Worker
    Worker-->>Queue: Job processed successfully

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• Fix translation worker HTML parsing and HEAD cache refresh #608: Makes changes to the same translation worker code (apps/translation-worker/src/index.ts), including modifications to cache refresh and HTML rendering behavior.

Poem

🐰 A queue now guides our translations true,
No more waiting in the request queue!
Jobs hop along with pending care,
While cache refreshes float through the air,
Async and swift—the worker's repair! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: moving translation cache refreshes from request handling to queue-based processing, which is the primary objective of the PR.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/translation-queue-refresh

---

_{Review rate limit: 0/5 reviews remaining, refill in 53 minutes and 29 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/deploy-translation.yml (1)

44-56: 💤 Low value

Consider adding development queue creation.

The workflow correctly creates the production queue capgo-translation-refresh with idempotent handling via the "already exists" check. However, the development environment in wrangler.jsonc uses a separate queue capgo-translation-refresh-development (see lines 66-83 of apps/translation-worker/wrangler.jsonc).

If development deployments go through a different workflow or are handled manually, this is fine. Otherwise, you may want to also create the development queue here or in a separate step.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy-translation.yml around lines 44 - 56, The workflow
currently ensures the production queue capgo-translation-refresh exists but
doesn't create the development queue capgo-translation-refresh-development; add
an idempotent creation step for capgo-translation-refresh-development (mirroring
the existing block for capgo-translation-refresh) so the development queue from
wrangler.jsonc is present during deployments; ensure you reuse the same pattern
(set +e, run bunx wrangler queues create capgo-translation-refresh-development
capturing output and status, print output, exit on success, and grep for
"already exists") and include the same CLOUDFLARE_API_TOKEN and
CLOUDFLARE_ACCOUNT_ID env variables.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/deploy-translation.yml:
- Around line 44-56: The workflow currently ensures the production queue
capgo-translation-refresh exists but doesn't create the development queue
capgo-translation-refresh-development; add an idempotent creation step for
capgo-translation-refresh-development (mirroring the existing block for
capgo-translation-refresh) so the development queue from wrangler.jsonc is
present during deployments; ensure you reuse the same pattern (set +e, run bunx
wrangler queues create capgo-translation-refresh-development capturing output
and status, print output, exit on success, and grep for "already exists") and
include the same CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID env variables.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ccc750a1-2d2f-4f3a-ad7e-008941387691

📥 Commits

Reviewing files that changed from the base of the PR and between 3954c53 and e579dbd.

📒 Files selected for processing (3)

• .github/workflows/deploy-translation.yml
• apps/translation-worker/src/index.ts
• apps/translation-worker/wrangler.jsonc