fix(infinity-agent-core): compaction inside child thread no longer panics on indexing#39
Open
shadaj wants to merge 1 commit into
Open
fix(infinity-agent-core): compaction inside child thread no longer panics on indexing#39shadaj wants to merge 1 commit into
shadaj wants to merge 1 commit into
Conversation
…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>
Deploying infinity with
|
| 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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When compaction triggered inside a child thread,
safe_spawn_point()returnedan in-memory index that included ancestor messages prepended to the history.
This index was used as
spawn_order_overridefor 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_ancestorsnow returnsancestor_prefix_lenas a thirdtuple element (how many messages at the front come from ancestor threads).
HistoryManagerstores this in aCell<usize>field.safe_spawn_point()subtractsancestor_prefix_lenso the returned indexis relative to the thread's own store.
apply_compaction()addsancestor_prefix_lento the split position (sinceancestors 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) reproducesthe 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