fix(share-backend): publish-data hardening — revoke idempotency, hidden_turns cap

[graydawnc]

What

Two follow-ups in the publish-data path, surfaced in the post-launch audit.

Idempotent revoke

The ownership SELECT had no revoked_at IS NULL clause. Re-revoking a tombstoned share would overwrite the original revoked_at with a newer timestamp:

• corrupts the audit trail
• shifts the row outside the 7-day orphan-sweep window — R2 artefacts go undeleted long after the share went 410

Plus a renderer-side consequence: the IPC handler does if (!r.ok) throw. The cross-device case (revoked on web, retried on desktop with stale local cache) used to toast revoke 404 for what was actually a successful no-op.

stateDiagram-v2
    [*] --> Live: publish
    Live --> Revoked: POST /api/revoke/:id<br/>200 + revoked_at=T0
    Revoked --> Revoked: POST /api/revoke/:id (retry)<br/>200, no write<br/>(revoked_at stays T0)
    Live --> [*]: 410 Gone (reader path)
    Revoked --> [*]: 410 Gone (reader path)<br/>orphan-sweep at T0 + 7d

    state Revoked {
        [*] --> AuditTrailPreserved
    }

Loading

Fix shape:

• not owned / doesn't exist → 404 NOT_FOUND
• owned but already revoked → 200 { ok: true } (no D1/KV/R2/audit write)
• owned and live → revoke as before (D1 → KV → R2 + audit)

The renderer's existing if (!r.ok) throw converges cleanly without any client-side change.

Array bounds on turns / turn_order / hidden_turns

All three previously capped at 500. Measured against real-world session-length distribution on actual power-user dbs:

Distribution	turns
p50	36
p90	408
p95	774
p99	1,740
max	4,565

→ 9.2% of real sessions exceed 500 turns. 500 was far too tight; the cap was rejecting legitimate publishes.

At the same time hidden_turns had NO cap at all — a crafted payload could ship a multi-million-entry array and bloat zod validation memory before the cross-reference refine ran.

Fix:

• turns, turn_order, hidden_turns → .max(20_000)
• ~4× the largest real session as headroom (nobody legitimate hits it)
• still acts as a validator-CPU sanity guard before MAX_SNAPSHOT_BYTES (2 MB) would have rejected the payload at the body-cap stage
• the body cap remains the real defense

Verification

• revoke: 200 on already-revoked + assert original revoked_at preserved
• tests/_helpers/fakes.ts: new matcher for SELECT revoked_at FROM published_shares so the regression exercises the production query path

pnpm --filter @spool/share-backend test → 175/175 green.

Risk

Pure correctness improvement on both fronts. The 200-idempotent shape matches what most callers already expect from an unpublish action. Raising the turns cap from 500 → 20,000 unblocks ~9% of real sessions that previously failed validation; the body-bytes ceiling (2 MB) is unchanged.

Submitted by @graydawnc.