Repository navigation
storage: acceptSignedUpload is unreachable end to end — no mounted PUT route, and the signing secret is closed over #145
Description
What
acceptSignedUpload is public API, tested, and — after the 2026-08-18 sweep — correct. It is also unreachable from a real app:
- No mounted PUT route. Nothing in the framework serves the upload target a
grantUploadURL points at.packages/cli/src/dev-storage.tsmounts a read route only. - The signing secret is closed over inside
localDriverand noStorageDrivermethod exposes it, so a route an app writes itself cannot verify the signature either.
packages/storage/CLAUDE.md already records (1). (2) is what makes it more than a missing route: the seam an app would need is not there.
Why it matters
docs/architecture/17-uploads.md documents the round trip as a working flow. Every piece of it is real and unit-tested; the flow is not runnable. That is the shape the framework exists to prevent — the sweep found three separate defects inside this surface (the base-path mismatch, requireChecksum being unreachable, shared assets refused as cross-tenant), and all three survived precisely because no end-to-end path exercises them.
Fix direction
Decide where the upload route lives — framework-mounted like the read route, or an app-written route plus a StorageDriver seam that hands over a verifier (not the secret). Then make examples/dummy exercise the round trip, which is what would have caught all three.
Found by the multi-agent bug sweep, 2026-08-18.
Activity
developerz-ai commentedon Aug 18, 2026
I couldn't reliably classify or scope this report right now, so I haven't guessed or handed it off. A maintainer will review it.
🤖 Posted by developerz.ai — the maintainer agent, not a human.
developerz-ai commentedon Aug 18, 2026
Thanks for this detailed report. This is a clear bug:
acceptSignedUploadis implemented and tested but cannot be reached from a real application due to:localDriverwith no public seam to access itThis matches the pattern of the three defects found in the sweep — all survived because no end-to-end path exercises them.
I'll label this as a bug and proceed to scope the fix.
🤖 Posted by developerz.ai — the maintainer agent, not a human.
developerz-ai commentedon Aug 18, 2026
Scoped task
Problem:
acceptSignedUploadis unreachable from real apps — no PUT route exists and the signing secret is not exposed through StorageDriver.Acceptance criteria
Areas
packages/storage/driver.ts— interface needs verifier methodpackages/storage/driver-local.ts— localDriver needs to expose verifierpackages/storage/upload.ts— acceptSignedUploadpackages/storage/grant.ts— grantUploadpackages/cli/src/dev-storage.ts— needs PUT routeexamples/dummy— needs full round-trip testGroups
Confidence: 0.8
🤖 Posted by developerz.ai — the maintainer agent, not a human.
developerz-ai commentedon Aug 18, 2026
Want to submit a fix? I'll scope it and flag it for the maintainer to pick up.
🤖 Posted by developerz.ai — the maintainer agent, not a human.
fix(tier0,tier1): the contracts that said "never throws" threw, and a…
fix(scraping,admin,jobs,action,storage,render,cli)!: close the known-…
feat(scripts,framework)!: four gates, and the last ten known gaps (#219)
sebyx07 commentedon Aug 20, 2026
The seam is fixed in #219. The
PUTmount is not, and this issue stays accurate about that — reopening or a follow-up is warranted for the mount alone.Both halves of the premise verified first: no
PUTanywhere inpackages/(storageRoutesreturns exactly oneGET; the onlymethod: 'PUT'occurrences aregrant.tsdeclaring the signed method andupload-client.tsissuing the fetch), and the secret closed over inlocalDriver's factory, reachable through no member ofStorageDriver.The seam was the real defect, and it was exactly one member wide.
StorageDriveralready exposessignedUrlBase— hoisted onto the interface, by its own comment, "so the minting half and the verifying half cannot state it twice". The secret is the other half of that same pair and was never hoisted. That is whyacceptSignedUpload's requiredsecret:had no value a route could put in it, and why thePUTwas never mounted.New
StorageDriver.verifySigned?({ url, clock })— verification, never the key. A member that returned the secret would let any holder of a driver mint a URL for any key, and would put it in everyJSON.stringify(disk)a log performs.acceptSignedUpload({ url, disk, orgId, bytes, declaredContentType })now works with no secret in the call at all. New codeX_STORAGE_URL_UNVERIFIABLE(500, not 403 — nothing is wrong with the caller's URL, and reporting it as 403 sends the on-call hunting an attacker who is not there).A mutation gap caught during the work, worth recording: the first
verifySignedtest passed one clock to both the driver and the call, so "ignores the caller's clock" was not caught. A test where the disk is built with a boot clock and the caller passes a later one — a route's real shape — catches it. Without that, every expiry assertion in a suite using this seam would have passed for the wrong reason.