Daemon + manual fetch/shelve concurrency — won't fix (v1) #20

New issue

Open

opened 2026-06-29 22:21:03 +00:00 by erik · 0 comments

erik commented

2026-06-29 22:21:03 +00:00

Owner

We've decided not to build the IPC layer (HTTP /v1/inflight endpoint or lock-file polling) needed to coordinate this in v1. The constraint is: don't run fetch/shelve while the daemon is active on the same root. Stop the daemon first, or manage roots either via daemon or manually — not both at once.

The worst case if the constraint is violated is a spurious re-upload of a just-materialized file. This is wasteful but not data-corrupting; state transitions are serialized by the SQLite transaction.

If this becomes a real pain point (e.g., users want to fetch before going offline without stopping the daemon), the preferred fix is Option A: a small loopback HTTP endpoint POST /v1/inflight/{add,remove} on the existing status API, protected by the bearer token. Option B (polling .dropbear/inflight/.lock files) is the fallback if Option A requires too much new status-API surface.

dropbear fetch and dropbear shelve register paths as in-flight on a per-root shelve.Set held by the daemon. When both are running against the same root simultaneously, the daemon's watcher can see a mid-operation file state and fire a spurious re-upload. We've decided not to build the IPC layer (HTTP /v1/inflight endpoint or lock-file polling) needed to coordinate this in v1. The constraint is: don't run fetch/shelve while the daemon is active on the same root. Stop the daemon first, or manage roots either via daemon or manually — not both at once. The worst case if the constraint is violated is a spurious re-upload of a just-materialized file. This is wasteful but not data-corrupting; state transitions are serialized by the SQLite transaction. If this becomes a real pain point (e.g., users want to fetch before going offline without stopping the daemon), the preferred fix is Option A: a small loopback HTTP endpoint POST /v1/inflight/{add,remove} on the existing status API, protected by the bearer token. Option B (polling .dropbear/inflight/<sha>.lock files) is the fallback if Option A requires too much new status-API surface.

erik self-assigned this

2026-06-29 22:21:03 +00:00