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

fix(webllm): a résumé reset fences the stale analysis run but never aborts it

Closed
  • Is something wrong?
#1,103 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
ai, frontend

Research direction

Start in src/hooks/useResumeAnalysisLlm.ts, especially the resetKey effect, AbortReason handling, and catch path; inspect acquireInference in src/lib/webllm/web-llm.ts:380. Add coverage for reset during streaming and model load, verify reset does not report a user abort, and check src/lib/analytics.ts if a reset reason is emitted. Run npm run typecheck and the scoped tests.

Written by the indexing model from the issue text.

Description

bug gaal ready-for-agent

Problem

#1100 (for #1099) makes a résumé reset safe for the panel, but it does not stop the stale run. The resetKey effect in src/hooks/useResumeAnalysisLlm.ts bumps runSeqRef and clears inFlightRef. After that, every status write and every telemetry call from the stale run is gated on isCurrent(). It never calls abortControllerRef.current?.abort(...), so a stale run that is past model load keeps generating tokens on the GPU until it finishes or hits its phase deadline.

Because #1100 frees inFlightRef right away, the user can press Analyze on the new résumé while the stale run is still generating. Both runs then drive the same engine. acquireInference is a reference counter, not a lock (src/lib/webllm/web-llm.ts:380), so nothing in our code serializes the two. What happens then is up to web-llm: the new run may queue behind the stale one or the two may interleave. Either way the stale work is wasted, and on a slow device it can use most of a phase deadline.

The comment #1100 added above the reset effect also says the hook has "no AbortController". That was true on #1100's original base but has been false since #1098 merged. After the rebase both mechanisms are in the file.

Proposed fix

  • Add an abort reason for a reset (for example "reset" in AbortReason). In the resetKey effect, abort the active controller with that reason alongside the sequence bump.
  • Keep the runSeqRef fence. It still covers a reset during loadEngine, which has no cancel path.
  • In the catch, a "reset" abort writes no status and does not emit trackAnalysisAborted with reason: "user". Either skip the event or emit reason: "reset". If it is emitted, document the new value in src/lib/analytics.ts.
  • Correct the reset-effect comment so it describes the actual mechanism: abort plus sequence fence.

Acceptance criteria

  • A test resets mid-phase and asserts the active AbortController was aborted with the reset reason, and that the phase's streaming call received an aborted signal.
  • A reset during model load still leaves status idle and never shows the old résumé's findings. The existing #1100 test stays green.
  • A reset never emits trackAnalysisAborted with reason: "user". A user Stop behaves as #1098 shipped it.
  • The reset-effect comment no longer says the hook has no AbortController.
  • npm run typecheck and the scoped tests are green.

Dependencies

Follows #1100. Start after it merges.

Dominant language
TypeScript
Stars
11
Forks
4
No merged PRs in 30d

Getting set up

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 offlinecv/OfflineCV

All issues in offlinecv/OfflineCV

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.