Allow TreeWalkerSession to call WalkTree multiple times
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 334
- Forks
- 61
- PR merge metrics
- No merged PRs in 30d
Description
Today a TreeWalkerSession can only call WalkTree one time. This is because the internal CancellationTokenSource (walkTreeCts) is created in the constructor, and cancelled at the end of WalkTree to make sure all tasks get cleaned up.
However, there is a common pattern to intentionally halt the tree walker by throwing an exception. The application then retries walking the tree at a later time depending on the scenario.
- E.g. Halt tree walker in BeforeVisitNode due to hitting a rate limit, then retry walking the tree in 1 minute.
- E.g. Halt tree walker to wait for an event, then walk the tree again.
The issue is because TreeWalkerSession can only call WalkTree once, the application must initialize a new TreeWalkerSession for every retry attempt. Even though all the same parameters are often used. Being able to use the original TreeWalkerSession would simplify and optimize the multi-WalkTree scenarios.
Solution idea:
- Recreate the walkTreeCts at the top of WalkTree. This would allow WalkTree to be called multiple times.
- Before recreating walkTreeCts in WalkTree, consider if we should cancel and dispose the existing walkTreeCts.
- We also need to keep the initialize walkTreeCts in the constructor since some applications call VisitNode instead of WalkTree, and we don't want to break them.
- Unrelated, but we should also call walkTreeCts.Dispose() after calling Cancel() in the CancelWalkTree() method.
Contributor guide
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.
Research direction
Start by locating TreeWalkerSession and read the constructor, WalkTree, VisitNode, and CancelWalkTree implementations, focusing on the walkTreeCts lifecycle. Verify how cancellation and disposal behave across repeated WalkTree calls and cancellation paths. Done means a session can retry WalkTree safely while existing VisitNode behavior remains intact and the relevant tests pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 66/100