Skip to content

fix(infinity-agent-core): compaction inside child thread no longer panics on indexing#39

Open
shadaj wants to merge 1 commit into
mainfrom
sandbox-61b60cff-d7ba-496e-922e-0ca623d7b6d6
Open

fix(infinity-agent-core): compaction inside child thread no longer panics on indexing#39
shadaj wants to merge 1 commit into
mainfrom
sandbox-61b60cff-d7ba-496e-922e-0ca623d7b6d6

Conversation

@shadaj

@shadaj shadaj commented Jun 18, 2026

Copy link
Copy Markdown
Member

When compaction triggered inside a child thread, safe_spawn_point() returned
an in-memory index that included ancestor messages prepended to the history.
This index was used as spawn_order_override for the compaction grandchild,
but the child's actual store only contained its own messages — causing a panic:
"range end index X out of range for slice of length Y".

The fix:

  • load_history_with_ancestors now returns ancestor_prefix_len as a third
    tuple element (how many messages at the front come from ancestor threads).
  • HistoryManager stores this in a Cell<usize> field.
  • safe_spawn_point() subtracts ancestor_prefix_len so the returned index
    is relative to the thread's own store.
  • apply_compaction() adds ancestor_prefix_len to the split position (since
    ancestors occupy the beginning of in-memory history) and resets it to 0 after
    compaction (ancestors are consumed into the summary).

A regression test (compaction_inside_child_thread_does_not_panic) reproduces
the exact panic from issue #31 and uses insta snapshots to verify both the
compaction child's inherited history and the post-compaction history.

Fixes #31

Co-authored-by: Infinity 🤖 infinity@hydro.run

…nics on indexing

When compaction triggered inside a child thread, `safe_spawn_point()` returned
an in-memory index that included ancestor messages prepended to the history.
This index was used as `spawn_order_override` for the compaction grandchild,
but the child's actual store only contained its own messages — causing a panic:
"range end index X out of range for slice of length Y".

The fix:
- `load_history_with_ancestors` now returns `ancestor_prefix_len` as a third
  tuple element (how many messages at the front come from ancestor threads).
- `HistoryManager` stores this in a `Cell<usize>` field.
- `safe_spawn_point()` subtracts `ancestor_prefix_len` so the returned index
  is relative to the thread's own store.
- `apply_compaction()` adds `ancestor_prefix_len` to the split position (since
  ancestors occupy the beginning of in-memory history) and resets it to 0 after
  compaction (ancestors are consumed into the summary).

A regression test (`compaction_inside_child_thread_does_not_panic`) reproduces
the exact panic from issue #31 and uses insta snapshots to verify both the
compaction child's inherited history and the post-compaction history.

Co-authored-by: Infinity 🤖 <infinity@hydro.run>
@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Jun 18, 2026

Copy link
Copy Markdown

Deploying infinity with  Cloudflare Pages  Cloudflare Pages

Latest commit: dfbd9e4
Status: ✅  Deploy successful!
Preview URL: https://057fc75d.infinity-dc7.pages.dev
Branch Preview URL: https://sandbox-61b60cff-d7ba-496e-9.infinity-dc7.pages.dev

View logs

@shadaj shadaj marked this pull request as ready for review June 18, 2026 00:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Compaction thread spawned _inside_ a child thread leads to improper indexing

1 participant