It seems a bit suspicious to be catching the cancellation error here specifically. It looks like the test itself is attempting to insert the text, but the insert gets cancelled. Wouldn't that fail the test because the text did not successfully get applied?

I wouldn't expect the actual insertion to get cancelled in general, unless someone else is changes the file underneath. I would generally expect other requests (e.g. a classification request) to get cancelled if you change the file - but I don't think that would cause the edit application itself to throw a cancellation?

Cancellations and retries happen in razorDocumentSynchronizer during the text insertion. Text actually gets inserted and document gets synchronized eventually (thus re-tries while wiating for expected completion item).

Though looking at the failures from the test run, I am catching them in the wrong place. At least some of the time synchronization appears to happen after the insertion/deletion (e.g. outside of insertText). I guess I could wrap test method itself including and after the modification operations.

At least some of the time synchronization appears to happen after the insertion/deletion (e.g. outside of insertText). I guess I could wrap test method itself including and after the modification operations.

So if the synchronizer is changing the document underneath you may have to catch the exception here, think I get that part now (since the edit may fail).

If you're seeing them thrown outside of the insert text part, you probably want to catch them in the actual synchronization code path then? Unless some caller of it needs to observe the cancellation.

it doesn't throw explicitly, at least not that I can easily see - I'll debug through that some more

Maybe the rejection is happening outside of the await? The rejection happens for either onCancellationRequested or setTimeout. I'm not sure if those events could be triggered separately from the await, and therefore cause the promise rejection to not be handled?

Debugging it still, unfortunately the issue is pretty intermittent on my machine (though CI machines have no problem hitting it :) ).

fwiw the code in there seems quite complex and a bit suspect in general. I wonder if it would be worth rewriting it instead of spending a bunch of time debugging. I'm no TS expert, but the multiple events rejecting the same promise, possibly entirely outside of the await context seems very prone to random issues.

Unfortunately, I am neither TS expert nor razorDocumentSynchronizer expert, so I'm not up to the task of re-writing it. I debugged some more and tried a few things.

Cancellation seems to occur in request processing in request queue when previous requests of the same type is already running, which makes sense I guess. As we are inserting the text, we may hit previous request still running.

The unhandled error that jest sees is simply a string, not vscode.CancellationError. Also copilot did say it's a good practice to catch errors from rejection, so I added some catch clauses to the promises that seem to be the source of the errors. It seems to work on my machine, unless it's just flaky and not hitting the issue locally. I pushed the current fix and will see if the tests are passing on the CI now.

After my last commit hover and rename tests are failing (though not on my box of course). I'll convert this PR to draft and mark with WIP while I figure out what's going on.