Parent: #45
Blocked by: P6 above
Delete the browser-side mesh reducer (mesh-worker.ts — hand-copied, untested, already-drifted from core: missing deliveryQueues entirely, naive last-writer-wins instead of the tested revision-based convergence) rather than migrate it; the client already treats the server's own state as authoritative on every patch. Retire the unfinished relay-worker.ts/relay-client.ts prototype (404s in the served deployment, untested, silently drops unknown methods) in favour of wire-mesh's own tested relay hub. Push subtree (vapid.ts through sw.ts) survives untouched.
Done (2026-09-16, PR #145). relay-worker.ts/relay-client.ts were already gone from the tree -- no trace found anywhere, so that half of this issue was already complete before this session picked it up. mesh-worker.ts itself is genuinely still live (instantiated by mesh-client.ts, imported by main.tsx) and was not deleted -- its own defect was narrower than the issue's original framing implied: applyPatch reimplemented a naive, partial CRDT merge for agent_upsert/room_upsert, unioning stale local subscribedRooms/members back onto whatever the server sent rather than overwriting. Confirmed as a real bug (not just theoretical) by writing a test against the original code before fixing it: the old logic silently resurrected a room or member the server had already removed. Fixed by having applyPatch overwrite directly from the server's own patch with no merge attempt -- correct because the worker holds a single connection to exactly one server, which has already computed the fully-merged, authoritative record before ever broadcasting it, matching MeshClient's own main-thread handler already treating the worker's state as something to re-fetch wholesale after every patch. The file had zero tests before; its pure reducer functions are now exported and directly unit-tested.
#52 is closed.
Parent: #45
Blocked by: P6 above
Delete the browser-side mesh reducer (mesh-worker.ts — hand-copied, untested, already-drifted from core: missing deliveryQueues entirely, naive last-writer-wins instead of the tested revision-based convergence) rather than migrate it; the client already treats the server's own state as authoritative on every patch. Retire the unfinished relay-worker.ts/relay-client.ts prototype (404s in the served deployment, untested, silently drops unknown methods) in favour of wire-mesh's own tested relay hub. Push subtree (vapid.ts through sw.ts) survives untouched.
Done (2026-09-16, PR #145).
relay-worker.ts/relay-client.tswere already gone from the tree -- no trace found anywhere, so that half of this issue was already complete before this session picked it up.mesh-worker.tsitself is genuinely still live (instantiated bymesh-client.ts, imported bymain.tsx) and was not deleted -- its own defect was narrower than the issue's original framing implied:applyPatchreimplemented a naive, partial CRDT merge foragent_upsert/room_upsert, unioning stale localsubscribedRooms/membersback onto whatever the server sent rather than overwriting. Confirmed as a real bug (not just theoretical) by writing a test against the original code before fixing it: the old logic silently resurrected a room or member the server had already removed. Fixed by havingapplyPatchoverwrite directly from the server's own patch with no merge attempt -- correct because the worker holds a single connection to exactly one server, which has already computed the fully-merged, authoritative record before ever broadcasting it, matchingMeshClient's own main-thread handler already treating the worker's state as something to re-fetch wholesale after every patch. The file had zero tests before; its pure reducer functions are now exported and directly unit-tested.#52 is closed.