Prep for usage: bulk API, export, WebSocket, mount hardening, E2E

[khaliqgant]

Summary

• Bulk API & Export: Bulk seed endpoint, workspace export (tar/patch), binary file support
• WebSocket push: Real-time file-change notifications via WebSocket
• Mount hardening: Conflict resolution, bidirectional sync improvements
• E2E infrastructure: Test script, workflow definitions for 6 phases (E2E, bulk/export, dev experience, CI/publish, hosted server, landing page)
• SDK updates: TypeScript SDK extended with bulk, export, and WebSocket client methods
• Design docs: Bulk export design, knowledge graph spec, mount hardening plan

This PR will be continuously updated as the workflows run.

Test plan

• E2E test: Go server + two mount daemons sync bidirectionally
• Bulk seed + workspace export
• WebSocket push notifications
• CLI: login/mount/seed/export
• CI pipeline: Go tests + SDK typecheck + E2E
• Hosted server deployment
• Landing page at relayfile.dev

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 18 additional findings in Devin Review.

[devin-ai-integration]

🔴 WebSocket connection torn down after every sync cycle due to short-lived parent context

The connectWebSocket method at internal/mountsync/syncer.go:425 derives readCtx from the ctx parameter of SyncOnce. Both callers (cmd/relayfile-mount/main.go:68-69 and cmd/relayfile-cli/main.go:365-366) create a short-lived timeout context (default 15s) per sync cycle: ctx, cancel := context.WithTimeout(rootCtx, *timeout) with defer cancel(). When SyncOnce returns and the timeout context is canceled, readCtx — a child of that context — is also canceled. This causes wsjson.Read(readCtx, conn, &event) in readWebSocketLoop to fail with context.Canceled, tearing down the WebSocket connection. On the next sync cycle, needsWS evaluates to true again (since handleWebSocketDisconnect sets s.wsConn = nil), causing a reconnect. This connect/disconnect cycle repeats every sync interval, making WebSocket real-time streaming completely non-functional — the connection never lives long enough to receive any live events.

Call chain showing the context propagation

run() creates context.WithTimeout(rootCtx, 15s) → passes to SyncOnce(ctx) → passes to connectWebSocket(ctx) → readCtx, cancel := context.WithCancel(ctx) → go readWebSocketLoop(readCtx, conn) → when run() returns, defer cancel() kills readCtx → read loop exits → handleWebSocketDisconnect sets wsConn = nil.

Prompt for agents

In internal/mountsync/syncer.go, the readCtx for the WebSocket read loop must NOT be derived from the per-sync-cycle ctx parameter. Instead, it should use a longer-lived context that survives across sync cycles.
Option 1: Store a long-lived cancel context on the Syncer struct, created once (e.g. in NewSyncer or on first connect), and use that as the parent for readCtx instead of the SyncOnce ctx.
Option 2: Use context.Background() as the parent for readCtx, relying on the wsCancel function for cleanup.
The fix at line 425 of internal/mountsync/syncer.go should change from:
readCtx, cancel := context.WithCancel(ctx)
to something like:
readCtx, cancel := context.WithCancel(context.Background())
This ensures the WebSocket read loop survives beyond a single SyncOnce call. The handleWebSocketDisconnect method already handles cleanup via wsCancel.

---

Was this helpful? React with 👍 or 👎 to provide feedback.