superhuman: draft-management commands fail against live backend (drafts list 400, get empty, discard 520)

[noahlevin]

superhuman: draft-management commands fail against the live backend

The superhuman CLI's draft-management surface does not interoperate with the current Superhuman backend. Reads (Gmail passthrough: messages list, messages query) and threads list work fine, and drafts new returns 200 — but drafts list, drafts get, and drafts discard all fail. Because drafts new "succeeds" while the read/list/discard paths fail, created drafts are effectively unmanageable.

Environment

• superhuman-pp-cli built from library/productivity/superhuman (pseudo-version v0.0.0-20260618052343-6f215c39f277, runtime 2026.6.1)
• Auth via auth login --disk (windowless Chrome-session mint — works well)
• Verified live against a real Superhuman account on 2026-06-18 and 2026-06-20 (identical results both days, so not a transient outage)

1. drafts list → HTTP 400 (root-caused + fix in PR)

$ superhuman-pp-cli drafts list --account <me> --agent
Error: POST /v3/userdata.getThreads returned HTTP 400: {"code":400}

Root cause: internal/cli/drafts_list.go posts an empty {} body to /v3/userdata.getThreads. The backend's BackendListFetcher requires a {filter:{type:"draft"}} discriminator — the exact lesson internal/cli/threads_list.go already encodes as PATCH(U3) (empty {} returns HTTP 400 from the backend). threads list --type draft (which sends that shape) succeeds live; drafts list 400s only because it never got the same shape.
Fix: send {filter:{type:"draft"}, limit, offset}. Verified live (released binary → 400; patched → 200 with the full draft threadList) + regression test. See PR.

2. drafts get <id> → empty / not-found

$ superhuman-pp-cli drafts get <draft-id> --account <me> --agent
Error: drafts get: <draft-id> not found

/v3/userdata.read returns no draft body in any of the wrapper shapes unmarshalDraftValue tries, even for a draft that exists (visible in threads list --type draft and in Gmail in:drafts). Note drafts get/readDraft build users/<uid>/threads/<draft-id>/messages/<draft-id>/draft reusing one id for both the thread and message segments, whereas real drafts have distinct thread-id vs message-id segments (e.g. threads/draft007cf1…/messages/draft00f93…) — a likely contributor. Needs the live userdata.read draft contract to fix confidently.

3. drafts discard <id> → HTTP 520

$ superhuman-pp-cli drafts discard <draft-id> --yes --account <me>
Error: POST /v3/userdata.write returned HTTP 520: {"code":520,"detail":"server-error"}

Persistent across ~10 retries over several minutes, on two separate days. drafts new uses the same userdata.write endpoint and returns 200, so the discard tombstone payload specifically is rejected at origin. Needs the live userdata.write delete/tombstone contract.

Secondary (separate bug): time-bomb test

internal/cli/send_test.go TestSendDryRun_ScheduleAt fails once the hardcoded 2026-05-20T08:00:00Z schedule date is in the past (send: --schedule-at must be in the future). go test ./... is red on main for this reason as of 2026-06-20. Worth switching to a relative future offset.

I've opened a PR for #1. Happy to help reproduce #2/#3 if useful, but they need the real backend contract to fix correctly.

[noahlevin]

Claiming the drafts list 400 portion — fix is up in #1304 (verified live + regression test). Leaving #2 (drafts get empty read) and #3 (drafts discard 520) open since they need the live userdata.read/write contract.

[noahlevin]

Update: #1304 now also fixes #2 (drafts get) — root cause was that real Superhuman drafts have a distinct thread id vs message id, but readDraft reused one id for both path segments; it now resolves via getThreads (matching either id), verified live. So #1304 covers list + get. #3 (discard) and the related drafts new CRDT-materialization gap remain — those need the live userdata.write tombstone contract.

[noahlevin]

Correction + sharper repro for #3 (discard). I earlier implied drafts new doesn't materialize a real Superhuman draft — that's wrong. Clean single-session test: a freshly created draft appears in getThreads immediately (CRDT count went up), is resolvable by drafts get, and drafts new returns 200. So create works.

discard is the only broken write: it POSTs {writes:[{path:"users/<gid>/threads/<id>/messages/<id>/draft", value:null}]} to /v3/userdata.write and gets HTTP 520 even on a fresh, materialized, gettable draft (so it's not a stale/deleted-draft artifact). drafts_discard.go already flags this body as a guess. Since writeMessage (create) and getThreads (list/get) both succeed against the same backend, the issue is isolated to the discard delete payload — needs Superhuman's real tombstone/delete shape. Also worth noting discardDraftBody reuses one id for both path segments (the same bug get had), so it'd also need the thread-id≠message-id fix once the delete shape is known.

[noahlevin]

Re #3 (discard): why it can't be fixed by guessing the REST body — it isn't a REST call. I instrumented the live Superhuman web client (hooked page-context fetch, XMLHttpRequest.send, and WebSocket.send) and discarded several drafts. The discards succeed in the UI, but during a discard the page emits only: users.active, profile, smartsend.getTimeRange, gmail/threads, metrics.write, userdata.read, userdata.getThreads — no userdata.write, no delete/discard endpoint, and zero WebSocket frames.

So the draft mutation never crosses the page boundary: Superhuman is an offline-capable PWA and routes CRDT mutations (incl. discard) through its Service Worker sync layer, which page-injected interception can't observe. Implication for the CLI: drafts discard's POST /v3/userdata.write {writes:[{path, value:null}]} isn't just a wrong payload shape — it's the wrong mechanism, which is consistent with the HTTP 520. Capturing the real contract needs DevTools (it sees Service Worker traffic) or the SW/CRDT sync protocol directly — maintainer territory. Flagging so nobody burns time guessing REST bodies. (drafts new/getThreads/userdata.read are genuinely page-context REST and work, which is why list+get were fixable in #1304.)