[nissa-seru]

TL;DR: since 0.14.0, when the first compile after a message is removed is a dry one, later compiles read message positions from before the removal. With the middle one of three messages removed, every later compile, dry or committing, then threw UncoveredDropError until something rebuilt the order, such as setting the strategy again. #161 made a dry run put _storeOrder back, but not _storeOrderSource, the listing that order was built from. This puts both back, and a dry refresh now extends a copy of the order instead of the one it puts back.

What happens

On main (58fa2012), with AutobiographicalStrategy({ recentWindowTokens: 30_000 }), three messages, and compiles at a 100k budget:

no removal, dry x3                 dry ok | dry ok | dry ok
middle removed, dry x3             removed m2 | dry ok | dry THROWS UncoveredDropError | dry THROWS UncoveredDropError
middle removed, commit x3          removed m2 | commit ok | commit ok | commit ok
middle removed, dry, commit        removed m2 | dry ok | commit THROWS UncoveredDropError | commit THROWS UncoveredDropError
middle removed, commit, dry, dry   removed m2 | commit ok | dry ok | dry ok
middle removed, dry, re-init       removed m2 | dry ok | dry THROWS UncoveredDropError | re-initialized | dry ok | dry ok

The hierarchical and adaptive paths behave the same. In the same probe, removing the first or the last of three messages, or the third of five, didn't throw, but the order still held the positions from before the removal.

Released hosts can meet this today. In connectome-host 0.10.0 to 0.10.2, the web panel's context curve dry-compiles the resident's manager each time it draws (buildContextCurve, src/web/panel-data.ts). So a removal, such as a module's removeMessage or a suppression from the web UI, followed by a look at the panel, can leave the resident unable to compile its next turns. agent-framework's main adds dry compiles of its own, such as previewActivation right after suppressMessages removes messages; those aren't released yet.

Why

refreshStoreOrder keeps _storeOrder for as long as the store hands it the listing object it was built from, _storeOrderSource. The first select after a removal gets a new, shorter listing and rebuilds the order from it. A dry select then put the order from before the removal back, but left _storeOrderSource pointing at the new listing. The next select saw the same listing object, kept the old order, and read each message's position as it stood before the removal, until a later change to the store made the order rebuild.

A second case: when a dry select's listing starts with the one the order was built from, refreshStoreOrder extends the order in place. The dry branch puts the order back by reference, so the order it put back could hold positions for messages its listing doesn't have. We know of no public path that reaches this, since every store add reaches onNewMessage, which refreshes the order before any later compile. The copy keeps the restore true anyway, and the new test reaches the case directly.

Changes

• src/strategies/autobiographical.ts:

  • select()'s dry branch saves and restores _storeOrderSource together with _storeOrder;
  • during a dry select, refreshStoreOrder extends a copy of the order. A committing refresh still extends it in place.

• test/dry-run-preview.test.ts:

  • The removal test runs four layouts on both paths: the first, middle and last of three messages, and the third of five. Each runs with and without a committing compile before the removal, followed by a dry compile, then by two dry or two committing compiles. After every compile it checks that the order matches the listing it was built from. After a committing compile, it also checks that this is the current listing.
  • A new test refreshes the order with a longer listing during a dry select. It checks that the order the select found is unchanged, and that a committing refresh still extends in place.
  • The restore test also covers _storeOrderSource, and _imageWatermark and _postStripMemo, which the dry branch already put back.

  With main's source, the restore, removal and copy tests fail. With only the restore fix, the copy test fails. All three pass here.

• A fixed changelog fragment.

Tests

npm test at 1676968d in a clean checkout: 1209 tests in 178 suites, 1209 pass and 0 fail, on Node v24.19.0. Not run on Node 20, which CI also runs.

---

Written by Oscar-1005 (Claude Opus 5.5). Ada-1017 found it from agent-framework and wrote the first reproduction. Myrtle-2415 (Claude Opus 5.5) reviewed it.

[nissa-seru]

@Anarchid @slimepriestess Please review this fix for a regression in 0.14.0. When the first compile after a message is removed is a dry one, later compiles can keep throwing UncoveredDropError, and connectome-host 0.10.x's web panel runs a dry compile each time it draws. If you don't object, we'll merge it not before 18:00 UTC today, October 14. The description has the reproduction and the cause.

— Oscar-1005

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Dry compiles now restore _storeOrderSource with _storeOrder and copy the order before extending it.

• Dry compiles keep message positions tied to their listing.

git diff --check passed. Tests were not run during this review.

_{Reviews (1) · Last reviewed commit: "fix(autobiographical): a dry refresh ext..." · Reviewed by Greptile}

[slimepriestess]

Read after merge, at dc10873: the fix holds. We missed your 18:00 UTC window, so this is the read you asked for, after the fact. It found nothing to undo.

What we ran, on a worktree at the merge commit, with npm test (node --test over dist/, rebuilt by tsc; we checked that no stale test outputs were left in dist/):

• At dc10873: 1,209 tests, all pass.
• The listing not put back (this._storeOrderSource = saved.storeOrderSource; removed): four tests fail:
  • "records no chunk and queues no compression";
  • "records no chunk at a preview's overridden chunk size";
  • "puts back whatever a dry select wrote, on a throw too";
  • "leaves later compiles working when it is the first compile after a removal", the regression test for the bug itself.
• A dry refresh writing into the saved order (the copy new Map(this._storeOrder) replaced by this._storeOrder): one test fails, "extends a copy of the store order when a dry select reads a longer listing".

So both halves of the fix, putting back the order with its listing and extending a copy, go red when undone. Thank you for the reproduction table in the description; it made the cause quick to confirm.