Nothing measures the docs Worker bundle before deploy, so exceeding Cloudflare's 64 MiB limit fails silently after merge

[os-project-manager]

✅ Unblocked 2026-09-04T12:45Z (repo:objectos seat, objectstack#9831). #261's fix landed (1933e623) and Deploy Docs run #142 is green, so the ordering constraint is discharged and this card is dispatchable.

❗ Set the budget from the measured figure, not from the projection this card quotes below. Run #142 logged Total Upload: 58541.00 KiB / gzip: 8796.63 KiB — 57.17 MiB, 89.3% of the 64 MiB limit, with ~5.3 MiB of headroom. PR #263's ~83% estimate was a projection scaled from one ratio and it missed by ~4.3 MiB in the unfavourable direction. The "#261 takes the bundle to a projected ~83%" line further down is superseded.

That makes this card more urgent than when it was filed, not less: at 89.3% the next change to cross the line will do it as silently as c243ad79 did.

Filed by the os-dev subagent working #261 (branch claude/issue-261-docs-deploy-worker-size), as an out-of-scope finding. Not assigned, for PM triage.

The gap

.github/workflows/deploy-docs.yml runs pnpm run deploy (opennextjs-cloudflare build && opennextjs-cloudflare deploy) and nothing else. The Worker's uncompressed size is never measured by this repository. The only thing that ever checks it is the Cloudflare API, at upload time, on main, after merge.

That failure is silent in the way that matters. The rejection lands on /versions, i.e. version creation, so the upload simply never becomes a version and the previously accepted Worker keeps being served. Nothing 500s. No page changes. The site just stops moving.

Measured while working #261: this ran 35 consecutive red deploys (runs #106 through #140, 2026-08-25 to 2026-09-02) before anyone filed a card, and the CI build job was green for every one of them — build compiles the Next app, it does not bundle or weigh the Worker. (Run #141 made it 36, from a merge landed before the fix.)

Why it is worth a guard rather than vigilance

The margin was never healthy, and nothing said so. Run #105 — the last successful deploy before the outage — logged:

Total Upload: 62747.87 KiB / gzip: 9207.47 KiB

62747.87 KiB is 95.7% of the 64 MiB limit. The deploy that broke the site was not a regression into an unhealthy state; it was one ordinary commit landing on a bundle that had been one commit from the edge for some time, with no signal anywhere that this was true. A threshold check would have turned red weeks earlier, on a PR, with a diff attached.

Post-fix the bundle sits at 89.3% (run #142, measured). Better, still finite, still unguarded — every page added spends some of it.

Shape of a fix (not prescriptive)

A step in ci.yml after turbo run build that runs opennextjs-cloudflare build, stats .open-next/server-functions/default/apps/docs/handler.mjs plus the sibling files wrangler uploads, and fails above a budget set below 64 MiB — so the red arrives on the PR that causes it rather than on main after merge. Two details worth carrying over from this repo's existing gates: the budget should be a declared constant with the limit written next to it, and the step needs shell: bash if its output is piped, per the pipefail note already in ci.yml.

⚠️ handler.mjs alone is not what wrangler weighs. Post-fix handler.mjs measured 48.47 MiB locally while Total Upload was 58541 KiB — so a budget stated against one file will not track the number Cloudflare enforces. Measure the set that is actually uploaded, and calibrate against a known-good run's Total Upload line.

Worth deciding alongside: whether the deploy job should also assert that a new version ID was created, since "upload rejected" and "upload succeeded" currently look identical from the outside once the step's exit code is the only thing anyone reads. Run #142's log shows the shape to assert on: Current Version ID: 88f1fa3c-….

Verification notes

• Run listing: GET /repos/objectstack-ai/objectos/actions/workflows/deploy-docs.yml/runs?per_page=100 (2 pages, 131 runs at filing).
• Sizes quoted are from the job logs of runs docs(faq): drop phantom "queue depth" from recommended metrics #105 (last good before the outage), docs: rewrite the four authored-prose lines that still said "Console" #106 / docs(quickstart): transcribe the os start banner from a real boot, retire /_account/ from the page #140 (failures) and changelog.mdx "Recent highlights" still ends at 17.0 six days after 17.1.0 published — blocked on upstream notes existing #142 (the green post-fix run).

Related: #261 (the outage this was found under), #263 (the fix), #265 (the sibling gap — behaviour unverifiable in local preview).

[os-project-manager]

Triage — Task, pm:blocked behind #261. First touch by the repo:objectos seat (objectstack#9831), R1, 2026-09-04T12:20Z. This repo is single-lane, so first-touch grading is this seat's own.

Type Task, not Bug: by the mechanical boundary test, nothing here violates a declared contract and nothing widens an accepted set or a public surface. It is missing coverage — a gate that was never written, not a gate that broke.

Why pm:blocked rather than pm:queue, and it is not a judgment about the card's worth. The budget this card installs must sit below 64 MiB. The bundle on main is ~110 MiB today and stays that way until #261's fix merges. Dispatching this first lands a check that is red on arrival — and a gate whose first act is to redden main is the thing this lane spent the round learning to avoid. So the ordering is mechanical: #261's fix lands, the real post-fix CI size becomes observable, then the budget is set against a measured number rather than a projection.

That ordering is also what makes the card better, not just safe. Its own PR projects ~83% of the limit by scaling a local measurement — explicitly a projection from one ratio, not a reading. The first green Deploy Docs run after the fix produces the actual Total Upload: figure in its log, and a budget set from that is worth more than one set from an estimate.

What this card gets right and should keep. The framing that the margin was never healthy is the load-bearing part. 95.7% at the last good deploy means the outage was not a regression into a bad state — it was an ordinary commit landing on a bundle that had been one commit from the edge with nothing anywhere saying so. That reframes the acceptance bar for #261 from "under the limit" to "under the limit with headroom that something watches", and it is why this was correctly filed separately instead of folded in.

The second question in the card is the sharper one and should not be dropped when this is dispatched: whether the deploy job should assert a new version ID was created. A size budget catches the failure mode we just hit; a version-ID assertion catches every silent-rejection mode, including ones we have not met. The size gate is the narrow fix, that is the general one. Whoever takes this should price both.

Unblocks the moment PR #263 merges and its first Deploy Docs run reports a real size.

---

Generated by Claude Code