[TS Calls][Research] Capture stopped-path frontiers for article experiments
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- kotlin
- Domain
- devtools, testing-qa
Research direction
No files or tests are named. First identify a concrete consumer, research question, and fields unavailable from #364 decision events; if none exists, leave the work deferred. For an approved scope, define detached stopped-state ownership and bounded retention, then add focused tests for observer failure isolation, decision preservation, and separation from completed or replay-confirmed results.
Written by the indexing model from the issue text.
Description
Follow-up to #364. Part of #360. Optional research support for #385.
Goal
Capture stopped-state information only if an identified experiment requires data unavailable from existing unknown-call decision events.
Start condition
First name the consumer, the research question and the fields it cannot obtain by aggregating #364 events. Basic call counts, model decisions and stop-site frequencies do not justify a new snapshot API. If no concrete consumer needs a snapshot, leave this work deferred.
#364 provides decision callbacks only. It deliberately provides neither persistent path history nor stopped-frontier snapshots.
Scope
- Add opt-in capture orthogonal to the fallback setting only for the demonstrated consumer.
- Capture detached data rather than retaining live TsState/TsContext objects or allocation counters.
- Include the minimum stopping event, relevant signatures/statements and constraint status needed by that consumer.
- Add history or textual constraints only when explicitly required; do not serialize the entire engine state.
- Prefer experiment-owned aggregation/storage over changes to generic usvm-core primitives.
- Keep captured stopped states separate from completed execution states and generated tests.
- Define bounded retention and ownership with the consumer.
Definition of Done
- The consumer and required information are documented before implementation.
- Capture does not alter exploration decisions; observer failure isolation and detached ownership have focused tests.
- A stopped snapshot is never counted as a completed/replay-confirmed result.
- Deliver only the scoped research support in a separate PR when needed.
This issue does not block #365/#366, the census, or baseline evaluation in #385. It becomes a prerequisite only if the chosen measurement demonstrably requires it.
- Dominant language
- Kotlin
- Stars
- 33
- Forks
- 27
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 15
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from UnitTestBot/usvm
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
UnitTestBot/usvm#388 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
UnitTestBot/usvm#384 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
UnitTestBot/usvm#382 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
UnitTestBot/usvm#379 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
UnitTestBot/usvm#368 ·
All issues in UnitTestBot/usvm
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
libre-tube/LibreTube#8803 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Telegram !!! Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Xposed-Modules-Repo/com.fuck.iab#24 · 3 comments · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
SimonHalvdansson/Harmonic-HN#361 ·