|
| 1 | +--- |
| 2 | +title: "Workspace + corpora connection is slow-to-hanging, and the auth token won't persist" |
| 3 | +lede: "The Corpora Curator sits at 'connecting…' and the workspace switcher at 'loading…' — corpora never arrive — while the didi session drops within a minute of signing in, forcing a re-login. Two symptoms that most likely share one root cause." |
| 4 | +date_created: 2026-08-02 |
| 5 | +date_modified: 2026-08-02 |
| 6 | +authors: |
| 7 | + - Michael Staton |
| 8 | +augmented_with: |
| 9 | + - Claude Code on Claude Opus 4.8 |
| 10 | +semantic_version: 0.0.0.1 |
| 11 | +tags: |
| 12 | + - Issue |
| 13 | + - Augment-It |
| 14 | + - Workspace-Auth |
| 15 | + - Transport |
| 16 | + - Performance |
| 17 | + - Debugging-Journey |
| 18 | +status: Active |
| 19 | +--- |
| 20 | + |
| 21 | +# Workspace + corpora connection is slow-to-hanging, and auth won't persist |
| 22 | + |
| 23 | +## Symptom (operator report, 2026-08-02) |
| 24 | + |
| 25 | +On production **`augment.didi.sh`** in **Zen browser** (screenshot; the |
| 26 | +header's `tiling host · :3100` is a cosmetic shell label, not the origin): |
| 27 | + |
| 28 | +- The **Corpora Curator** header shows `connecting…` next to the `strategy` |
| 29 | + chip, and a separate `connecting` badge top-right; the `CORPORA` rail is |
| 30 | + empty. It stays this way — *"so slow it doesn't seem to work."* |
| 31 | +- The **workspace switcher** (top-right) shows `loading…` rather than a |
| 32 | + resolved workspace name. |
| 33 | +- **Connecting to workspaces is slow; connecting to corpora/strategies is |
| 34 | + *super* slow** — slow enough to read as broken. |
| 35 | +- **Auth doesn't persist:** signed in as `mpstaton@gmail.com`, then had to |
| 36 | + **re-login within a minute** of a login done a minute earlier. |
| 37 | + |
| 38 | +## Environment — production only; local is fine |
| 39 | + |
| 40 | +- **Production `augment.didi.sh`**, viewed in **Zen browser** (a Firefox |
| 41 | + fork the operator uses specifically to exercise the deployed surface). |
| 42 | +- **Local dev works well** — same code, same cloud SurrealDB. That is the |
| 43 | + load-bearing fact: it **rules out a logic bug** in the transport or |
| 44 | + curator (local runs them fine) and points at things that differ **only |
| 45 | + in production**: the deployed build, the prod infra, and the browser. |
| 46 | + |
| 47 | +## Ranked hypotheses (production-specific by elimination) |
| 48 | + |
| 49 | +1. **Zen/Firefox partitions the cross-subdomain session cookie.** The |
| 50 | + `didi_session` cookie is set by `id.didi.sh` and read by |
| 51 | + `augment.didi.sh` — different subdomains of `.didi.sh`. Firefox's Total |
| 52 | + Cookie Protection / Enhanced Tracking Protection (which Zen inherits and |
| 53 | + often hardens) can **partition or block** such a cookie as third-party, |
| 54 | + so it never comes back on the next request → the session looks absent → |
| 55 | + `4401` → the transport's auth-death path clears `user` (forced re-login) |
| 56 | + and retries glacially (30s) → reads as **"connecting… forever."** *First |
| 57 | + probe: load augment.didi.sh in Chrome/Safari; if auth persists there, it's |
| 58 | + Zen's cookie handling.* This single cause explains BOTH symptoms. |
| 59 | +2. **Production backend is under-resourced / cold.** The workspace-service |
| 60 | + ↔ cloud SurrealDB round-trip, or a small Railway instance (id-didi-sh |
| 61 | + OOM'd at 256 MB before its bump — augment's services may be similarly |
| 62 | + tight), makes the WS connect + `domain.list` genuinely slow even once |
| 63 | + authed. Explains the "super slow corpora" independent of the cookie. |
| 64 | +3. **The deployed build is stale.** The zombie-session fix (`9fc2543`: |
| 65 | + hourly/on-focus refresh + 4401 auth-death) and the transport reconnect |
| 66 | + fix (Group C) landed **after** the production flip (`4298be0`). If prod |
| 67 | + was never redeployed from current trunk, it lacks the refresh timer that |
| 68 | + would keep a session alive — compounding hypothesis 1. *Confirm what |
| 69 | + commit augment.didi.sh is actually running.* |
| 70 | + |
| 71 | +## Note on the cloud DB |
| 72 | + |
| 73 | +- Even with auth solid, corpora reads cross the network to the **cloud |
| 74 | + SurrealDB**; a cold/latent instance makes `domain.list` / |
| 75 | + `domain.assemble` slow. Local feeling "fine" may just mean a warm cloud |
| 76 | + connection at the time — worth timing directly in both environments. |
| 77 | +## Next probes (for the fix session) |
| 78 | + |
| 79 | +1. **Another browser first.** Load `augment.didi.sh` in Chrome or Safari. |
| 80 | + If auth persists and corpora load there, it's **Zen/Firefox cookie |
| 81 | + handling** (hypothesis 1) — the cheapest, highest-signal test. |
| 82 | +2. **Zen's cookie inspector.** On `augment.didi.sh`, check whether a |
| 83 | + `didi_session` cookie exists, its `Domain`/`SameSite`/partition state, |
| 84 | + and whether ETP is blocking it (Zen shows a shield / cookie report). |
| 85 | +3. **Network tab:** repeated `4401` socket closes at ~30s intervals? Is |
| 86 | + `POST id.didi.sh/api/session/refresh` firing, with credentials, and what |
| 87 | + does it return (200 refreshed vs 401)? |
| 88 | +4. **What commit is prod running?** Confirm `augment.didi.sh` was |
| 89 | + redeployed from current trunk — specifically that it has the zombie-fix |
| 90 | + refresh timer (`9fc2543`). The prod flip predated it. |
| 91 | +5. **Time the cloud read** directly (a `prove-*`-style `domain.list` over |
| 92 | + prod NATS) to size the DB-latency contribution separately from auth. |
| 93 | + |
| 94 | +## Relation to prior work |
| 95 | + |
| 96 | +- The transport's `4401` auth-death handling is **working as designed** |
| 97 | + ([[Session-Expiry-Turns-The-App-Into-A-Zombie]]) — but if the session can |
| 98 | + *never* persist (cookie-domain mismatch), that correct behavior presents |
| 99 | + as an endless "connecting" loop. The bug is upstream of the transport. |
| 100 | +- Not the same as [[Search-And-Add-Invokes-Never-Reach-The-Workspace]] |
| 101 | + (mount-time invoke loss) nor the refused-connection reconnect gap fixed |
| 102 | + in the transport suite (Group C) — though both should be ruled out. |
| 103 | + |
| 104 | +## See also |
| 105 | + |
| 106 | +- [[Session-Expiry-Turns-The-App-Into-A-Zombie]] — the auth-death contract this rides on |
| 107 | +- [[Search-And-Add-Invokes-Never-Reach-The-Workspace]] — a different "never connects" shape |
| 108 | +- [[Corpora-Builder-Harmony-Test-Registry]] — Group C (transport) + Group I (chain) coverage |
| 109 | +- `id-didi-sh/README.md` — the local-vs-deployed cookie note |
0 commit comments