this would could absolutely start at some arbitrary point in the future, and definitely after a point that hte cts had been cancelled/disposed. accessing .Token off of a Disposed cts will throw an exception. If _disconnectedSolutionTask was complete, then that could happen synchronously here inside TryKickOffPrimaryBranchWork_NoLock which is called in a method which must run to completion to setup state properly.

THat said... i also have a feeling the synchronous case cannot be hit, because we shouldn't be able to observe a cancelled token source synchronously since we're in the same lock that is used to cancel the cts in the first place.

❓ why do we need to dispose of the CTS here? Cancel being called should be sufficient, and it can be cleaned up with garbage collection as needed while safely passing a cancelled token around.

It's a good question. GEnerally speaking, it means:

1. we're a good cleanup citizen. We're not holding onto things longer than necessary.
2. we're also representing an invariant that this type wants to convey. when the ref count of this goes down, the CTS should be entirely finished with that at that point, and any accesses from that point on of _cts.Token should throw because it is a bug. This helps us have stronger invariants, which is always preferred in potentially racey code.

If we don't have this we actually risk doing bad things later and not catching it, would could lead to much harder to find issues.