WRITES_DISABLED + filecoin-pin-migration rollout: ETA + recommended path for non-migrated spaces?

[mklarmann]

Hi — looks like prod has WRITES_DISABLED=true in place since 2026-05-15 ~10:00 UTC (commit 33fa08d2 on storacha/w3infra is the currently deployed up.storacha.network/version SHA), alongside the filecoin-pin-migration@1.1.0 release. Reads work, writes return ServiceUnavailable: The "space/blob/add" capability is currently disabled.

I'm guessing this is intentional to keep large-space migrations consistent — that lines up with PR #706 ("improve large-space migration behavior...") and the new storacha space migrate flow.

A few quick questions if you have a moment:

1. Is there a public ETA for re-enabling writes once the migration wave is done? Days, weeks, "next month" — anything that helps operators plan.

2. For spaces that haven't been migrated yet, is the recommended path: (a) run storacha space migrate on each affected space and wait for it to land, or (b) sit tight until writes are re-enabled globally? The CLI docs read like (a) but I want to confirm before running migrations on production spaces.

3. Suggestion only — status.storacha.network currently shows "All Systems Operational, 100% uptime over 90 days", which is at odds with the deployed kill switch. A WRITES_DISABLED notice (or a "Filecoin migration in progress" banner) would save other folks the diagnostic time of correlating commits to deployments.

Thanks for the work on the migration — happy to provide more context if helpful.

[Tranquil-Flow]

Hi — confirming the same from our side. We're operating a privacy-focused storage layer (shadow-drive) on space did:key:z6MkpMaFBA3WPp3cMcsPbnAr4NCEbkxobvP9D8DqeGF5fj14.

Write disable confirmed globally, not per-space. We tested with two different CLI agents and two different spaces (including a fresh smoke-test space) — all get the same ServiceUnavailable from ucan-invocation-router.mjs. The disable-writes.js module in the open-source upload-service repo makes this clear: context.writesDisabled gates every write capability through applyWritesDisabled().

Migration source-pull failures are a separate issue. We ran storacha space migrate on May 27 after the write disable was already in effect. The migration's source-pull phase (reading from Storacha's PDP backend, not writing to it) got 69/129 shards through before the source provider started returning PDP pull queue backpressure. The remaining 60 shards (12 MB) failed deterministically. Three subsequent --resume and --retry attempts all hit the same backpressure.

Agree with OP: the status page showing "All Systems Operational" while writes are globally disabled is misleading. An operator shouldn't have to trace through Lambda source code to figure out why uploads are failing.

Any rough ETA on re-enabling writes? Days, weeks — anything helps us plan. Thanks for the migration work.