Two related gaps in log following:
src/api/logs.zig:253 — handleStream (serving GET /api/instances/{c}/{n}/logs/stream) builds a single SSE body containing retry: 3000, a connected event, and one snapshot event with the current tail, then returns. The connection doesn't stay open and no incremental events are ever pushed; clients only see updates because the SSE retry makes them reconnect and re-fetch the snapshot every 3s.src/main.zig:225 — nullhub logs -f prints nullhub logs -f is not stream-backed yet; showing current logs. and falls back to a one-shot dump.
Neither behavior matches what a /stream endpoint / -f flag advertises.
Suggested fix: implement real following (keep the SSE connection open and push appended lines, letting the CLI consume it), or — until then — document the snapshot+reconnect behavior on the endpoint and drop/adjust -f in the CLI help so it doesn't promise following.
Two related gaps in log following:
src/api/logs.zig:253—handleStream(servingGET /api/instances/{c}/{n}/logs/stream) builds a single SSE body containingretry: 3000, aconnectedevent, and onesnapshotevent with the current tail, then returns. The connection doesn't stay open and no incremental events are ever pushed; clients only see updates because the SSEretrymakes them reconnect and re-fetch the snapshot every 3s.src/main.zig:225—nullhub logs -fprintsnullhub logs -f is not stream-backed yet; showing current logs.and falls back to a one-shot dump.Neither behavior matches what a
/streamendpoint /-fflag advertises.Suggested fix: implement real following (keep the SSE connection open and push appended lines, letting the CLI consume it), or — until then — document the snapshot+reconnect behavior on the endpoint and drop/adjust
-fin the CLI help so it doesn't promise following.