Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[TS Calls][Research] Capture stopped-path frontiers for article experiments

Open
#373 0 comments 0 reactions 0 assignees View on GitHub

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

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from UnitTestBot/usvm

All issues in UnitTestBot/usvm

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.