Repository navigation
fix(tech-insights): pass the scheduler abort signal to fact retrievers - #12025
Open
mevan-karu wants to merge 1 commit into
Open
mevan-karu wants to merge 1 commit into
mevan-karu wants to merge 1 commit into
Conversation
Retrievers can now stop when a run times out or the backend shuts down. Signed-off-by: Mevan <mevan.karu@gmail.com>
mevan-karu
requested review from
a team,
Xantier,
kurtaking and
punkle
as code owners
November 12, 2026 08:49
Contributor
|
Important This PR includes changes that affect public-facing API. Please ensure you are adding/updating documentation for new features or behavior. Changed Packages
|
punkle
approved these changes
Nov 12, 2026
This branch has not been deployed
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.
Hey, I just made a Pull Request!
The tech-insights backend schedules each fact retriever with the
SchedulerService, but the function it registers ignores the scheduler's abort signal. The scheduler contract says a task function "may optionally accept an abort signal argument. When the signal triggers, processing should abort and return as quickly as possible." When a run exceeds itstimeout, the task is released so a new invocation can start, possibly on a different worker. Since retrievers never see the signal, a slow retriever keeps running after its timeout while another replica may already be running the same retriever.FactRetrieverContextintech-insights-nodegets an optionalsignal?: AbortSignal, and the backend now passes the scheduler's signal through tofactRetriever.handler. It aborts when the run times out or the backend shuts down. Existing retrievers keep working unchanged, and ones that want to stop early can pass the signal to their requests or check it between steps. The backend README mentions the new field in the section on writing retrievers.Storage on abort is deliberately left alone. Facts a retriever returns after the signal fires are still inserted as before, because skipping
insertFactswould quietly change behaviour for every existing retriever. That can be its own discussion if people want it.Tests cover the real scheduler handing the handler a signal, and a stubbed scheduler showing the handler gets the exact signal and sees it abort.
✔️ Checklist
Signed-off-byline in the message. (more info)