The offline write-queue (packages/core/src/queue/write-queue-v0.ts, #33) was a fully-tested pure module that nothing in the desktop imported. Approving a change while gitea was unreachable made gitea:applyChange call the client directly and throw, losing the write. This wires it in end to end.
What changed
queue-store.ts persists the queue next to the snapshot store, with the same degrade-to-empty-on-corruption discipline and an injectable path for tests.
applyChange extracts the guarded write into applyChangeLive and, on unreachability (any error that is not a GiteaApiError rejection), enqueues the intent — coalesced by (issue, axis) — instead of throwing, returning { ok, queued, pending }. A genuine GiteaApiError still surfaces, so a doomed write never replays forever.
reconcile drains the queue once a successful read proves gitea is reachable, re-reading so the board reflects the replays. Replays are idempotent (label plan.noop; assignee/milestone re-set to the same value). boot + stale reconcile report the pending count so the badge shows immediately offline.
Renderer:use-backlog threads pending; the OfflineBanner shows "N queued"; the chat approve message distinguishes a queued (offline) approval from an applied one.
Incidental
Wires vitest into the desktop workspace (it was missing, so the main-process suite could not run via yarn test).
Fixes a stale Capture copy assertion left by the earlier posh-copy pass.
Verification
queue-store.test.ts covers persist / reload / coalesce / replay-drain using the real core functions and real fs.
A one-off GITEA_LIVE smoke drove the real IPC handler against the real repo: an online re-estimate landed and self-reverted (est/2d→est/8d→est/2d on #34), and an offline approve returned {queued:true, pending:1} then drained to pending:0 on reconnect with the issue untouched. Not committed, per the repo convention that no test mutates gitea.
Scope: the propose→approve edit path (IssueChange). Capture→file (new-issue creation) is intentionally out of scope — a new issue has no number to coalesce on.
The offline write-queue (`packages/core/src/queue/write-queue-v0.ts`, #33) was a fully-tested pure module that nothing in the desktop imported. Approving a change while gitea was unreachable made `gitea:applyChange` call the client directly and **throw, losing the write**. This wires it in end to end.
### What changed
- **`queue-store.ts`** persists the queue next to the snapshot store, with the same degrade-to-empty-on-corruption discipline and an injectable path for tests.
- **`applyChange`** extracts the guarded write into `applyChangeLive` and, on unreachability (any error that is **not** a `GiteaApiError` rejection), enqueues the intent — coalesced by `(issue, axis)` — instead of throwing, returning `{ ok, queued, pending }`. A genuine `GiteaApiError` still surfaces, so a doomed write never replays forever.
- **`reconcile`** drains the queue once a successful read proves gitea is reachable, re-reading so the board reflects the replays. Replays are idempotent (label `plan.noop`; assignee/milestone re-set to the same value). `boot` + stale `reconcile` report the pending count so the badge shows immediately offline.
- **Renderer:** `use-backlog` threads `pending`; the `OfflineBanner` shows "N queued"; the chat approve message distinguishes a queued (offline) approval from an applied one.
### Incidental
- Wires `vitest` into the desktop workspace (it was missing, so the main-process suite could not run via `yarn test`).
- Fixes a stale Capture copy assertion left by the earlier posh-copy pass.
### Verification
- `queue-store.test.ts` covers persist / reload / coalesce / replay-drain using the real core functions and real fs.
- 9 main-process + 169 core unit tests green; 12 demo e2e green.
- A one-off `GITEA_LIVE` smoke drove the **real IPC handler** against the real repo: an online re-estimate landed and self-reverted (`est/2d`→`est/8d`→`est/2d` on #34), and an offline approve returned `{queued:true, pending:1}` then drained to `pending:0` on reconnect with the issue untouched. Not committed, per the repo convention that no test mutates gitea.
**Scope:** the propose→approve edit path (`IssueChange`). Capture→file (new-issue creation) is intentionally out of scope — a new issue has no number to coalesce on.
christian
added 1 commit 2026-07-12 23:56:10 +00:00
The offline write-queue (packages/core/src/queue/write-queue-v0.ts, #33) was a
tested pure module that nothing imported. Approving a change while gitea was
unreachable made gitea:applyChange call the client directly and throw, losing
the write. Now it's wired end to end:
- queue-store.ts persists the queue next to the snapshot store (same
degrade-to-empty-on-corruption discipline; injectable path for tests).
- applyChange extracts the guarded write into applyChangeLive and, on
unreachability (any error that is NOT a GiteaApiError rejection), enqueues the
intent — coalesced by (issue, axis) — instead of throwing, returning
{ ok, queued, pending }. A genuine GiteaApiError still surfaces (a doomed
write must not replay forever).
- reconcile drains the queue once a successful read proves gitea is reachable,
re-reading so the board reflects the replays; replays are idempotent
(label plan.noop, assignee/milestone re-set). boot + stale reconcile report
the pending count so the badge shows immediately offline.
- Renderer: use-backlog threads `pending`; the OfflineBanner shows "N queued";
the chat approve message distinguishes a queued (offline) approval from an
applied one.
Also wires vitest into the desktop workspace (was missing, so the main-process
suite couldn't run via `yarn test`) and fixes a stale Capture copy assertion
left by the earlier posh-copy pass.
Tests: queue-store.test.ts (persist/reload/coalesce/replay-drain, real core fns);
9 main-process + 169 core green; 12 demo e2e green. A one-off GITEA_LIVE smoke
verified an online write lands+reverts and an offline approve queues+drains
against the real repo (not committed, per the repo's no-mutating-test convention).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The offline write-queue (
packages/core/src/queue/write-queue-v0.ts, #33) was a fully-tested pure module that nothing in the desktop imported. Approving a change while gitea was unreachable madegitea:applyChangecall the client directly and throw, losing the write. This wires it in end to end.What changed
queue-store.tspersists the queue next to the snapshot store, with the same degrade-to-empty-on-corruption discipline and an injectable path for tests.applyChangeextracts the guarded write intoapplyChangeLiveand, on unreachability (any error that is not aGiteaApiErrorrejection), enqueues the intent — coalesced by(issue, axis)— instead of throwing, returning{ ok, queued, pending }. A genuineGiteaApiErrorstill surfaces, so a doomed write never replays forever.reconciledrains the queue once a successful read proves gitea is reachable, re-reading so the board reflects the replays. Replays are idempotent (labelplan.noop; assignee/milestone re-set to the same value).boot+ stalereconcilereport the pending count so the badge shows immediately offline.use-backlogthreadspending; theOfflineBannershows "N queued"; the chat approve message distinguishes a queued (offline) approval from an applied one.Incidental
vitestinto the desktop workspace (it was missing, so the main-process suite could not run viayarn test).Verification
queue-store.test.tscovers persist / reload / coalesce / replay-drain using the real core functions and real fs.GITEA_LIVEsmoke drove the real IPC handler against the real repo: an online re-estimate landed and self-reverted (est/2d→est/8d→est/2don #34), and an offline approve returned{queued:true, pending:1}then drained topending:0on reconnect with the issue untouched. Not committed, per the repo convention that no test mutates gitea.Scope: the propose→approve edit path (
IssueChange). Capture→file (new-issue creation) is intentionally out of scope — a new issue has no number to coalesce on.