fix(ui): mark Shell and Party Registry SSR routes with their UI release marker - #1031
Conversation
|
Review changes with Changed Files
|
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (14)
🧰 Additional context used📓 Path-based instructions (1)Source excerpt: Before changing files under `app/`, read [the application coding guide](./README.md).📄 CodeRabbit inference engine (app/AGENTS.md) Files:
🔇 Additional comments (5)
WalkthroughThe shell and Party Registry layouts now expose the UI build marker on their root elements. Tests check that each rendered layout has the expected marker. ChangesUI build marker
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~8 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to Both application roots expose their configured UI build marker, and Party Registry’s marker aligns with its API build. No actionable merge risk remains. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The layouts publish only each application’s build identifier and preserve their existing route outlets. No security issue was established, but the production source and validation of injected build identifiers remain unverified. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…se marker The Cloudflare public-URL proof reads data-build-marker from each app's cloudflare.routes.ssr page. The marker was dropped from the Shell home page with the login flow and from Party Registry when Contacts merged into it, so /en (Shell, anonymous) and /en/contacts (Party Registry) rendered none. Shell: carry it on the root layout wrapper, so every route and auth state renders it. Party Registry: its pages double as Shell module pages and its root layout is pinned to the generated scaffold, so carry it on a new [lang] layout that only the vertical's own Worker renders.
57c2816 to
4716c31
Compare
1 participant
Why the change
Most requests to the stage Catalog and commerce-customer-context Workers die with Cloudflare error 1102 because they need far more CPU than the 100 ms vertical cap, and this gives those two Workers a cap based on what stage analytics actually measured.
Special things to note
wrangler tailshows every 1102 asexceededCpu, killed at 100 ms when warm and at ~2100 ms when cold.Change outline
CPU budgets
How each Worker picks its budget
createModernConfig({ ..., cloudflareCpuMs = vertical }) - createCloudflareDeployment(build, { name, unitServiceBindings }) // always vertical + createCloudflareDeployment(build, { cpuMs, name, unitServiceBindings }) commerce-customer-context/modern.config.ts + cloudflareCpuMs: largeApiVertical catalog/modern.config.ts - createCloudflareWorkerConfig(env, { cpuMs: vertical, ... }) + createCloudflareWorkerConfig(env, { cpuMs: largeApiVertical, ... })Generated
wrangler.jsonapp-catalog limits: { cpu_ms: 100 → 3000 } app-commerce-customer-context limits: { cpu_ms: 100 → 3000 } every other app-* Worker limits unchanged