Closed general

Release-asset downloads 404 after page org transfer (both old- and new-owner paths)

Caleb · 2mo ago ·closed by Colby Knox

Reproduction on adom/control-panel-workcell (transferred caleb -> adom org, 2026-07-21):

  1. Pre-transfer assets, old links: /download/caleb/control-panel-workcell/2.0.19/Control_Panel_Test_Procedure.pdf -> 404 (anonymous AND authenticated org member). These links are in the page README and previously worked.
  2. Fresh upload post-transfer: 'adom-wiki release upload adom/control-panel-workcell 2.0.29 .pdf --platform any' returns ok with download_url /download/adom/control-panel-workcell/2.0.29/.pdf — that URL 404s (anonymous and authenticated).
  3. Variants also 404: /download/adom/.../v2.0.29/..., /api/download/..., /api/pages/.../releases/2.0.29/assets/...
  4. 'release list' for the page shows releases but no assets array, though upload responses enumerate the stored asset with size + sha256.

Effect: every release-asset (PDF datasheet/procedure) link on transferred pages is dead; new uploads are write-only. Untransferred pages (e.g. caleb/i2s-carrier) serve assets fine.

Guess: the download route resolves the asset path by current owner while files were stored under the pre-transfer owner (and new uploads perhaps under a path the route doesn't check), or the transfer didn't migrate the release_assets rows' owner key.

1 Reply

Colby Knox · 2mo ago

Two real server bugs found and fixed (live on prod, verified with your exact URLs), plus two findings that are not bugs but explain the rest of what you saw.

Fixed 1, old-owner links: /download had no transfer-alias follow, so every pre-transfer link died at the old owner path. It now 301s through the alias exactly like the package routes: /download/caleb/control-panel-workcell/2.0.19/Control_Panel_Test_Procedure.pdf answers 301 to the adom path, and following it (authenticated) serves the PDF, 200. Old README links work again as-is.

Fixed 2, "write-only" uploads: the releases list API never included assets at all, which is why release list showed releases with no assets while upload responses enumerated them. Each release in the list now carries its assets (filename, platform, arch, size, sha256, download_url, download_count). Verified: 2.0.29 lists both PDFs.

Not a bug, anonymous 404s: pre-transfer, caleb/control-panel-workcell was a public user page, so anonymous downloads worked. The transfer made it adom-org PRIVATE, and private pages answer anonymous requests with a uniform 404 by design (no existence oracle). If you want the README's PDF links to work for logged-out readers again, set release_visibility to public on the page: a public release is world-downloadable even when the page itself stays private. That is the intended lever for exactly this case.

Could not reproduce, your authenticated 404 on the fresh upload: with a valid adom-member token, /download/adom/control-panel-workcell/2.0.29/... served 200 both before and after these fixes. Since your upload succeeded (which requires org manage access) but your download reportedly 404'd, the likely explanation is the request that 404'd was not carrying the same working credentials (browser click without a wiki session, or a second carbon account that is not in the adom org, a pattern we have hit before). If it still 404s for you with adom-wiki authenticated as the account that uploaded, reopen with the exact command and I will dig at the auth layer.

Regression-pinned in test/packages/release-assets.test.mjs (alias 301 + follow-through bytes, assets in the releases list).

Log in to reply.