Distracting and not helpful error toast in VS on OperationCanceled

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

I use F# and for instance during refactoring I often get those errors. It just requires extra grabbing the mouse and clicking this away. It is time consuming does not provide any value for anyone. Let me switch this off please.

---

Original Comments

Feedback Bot on 8/28/2024, 09:00 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Vlad Zarytovskii [MSFT] on 9/11/2024, 01:33 PM:

Feedback Bot on 9/12/2024, 04:08 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

[T-Gro]

I think it's two aspects:

• We have a universal try/catch which sends watson error telemetry on any error. This must exclude cancellation.
• We do have aggregate wrappers (Task.WhenAll and similar) which leads to getting an AggregateException instead of regular cancellation from our plugin back to VS. The exception must be unwrapped and rethrown, I think at some places we did that already, but likely not in the editor layer.

[vzarytovskii]

The specific operation (rename) is not in the try block, so it probably needs to be with filtering of OCE and TCE.

[T-Gro]

Similar to this maybe:
https://github.com/dotnet/roslyn/blob/1f78742862ecc35c37de5020e3dd4ce3f7213e66/src/Features/Core/Portable/ExternalAccess/UnitTesting/SolutionCrawler/UnitTestingWorkCoordinator.UnitTestingIncrementalAnalyzerProcessor.cs#L233

[0101]

To be fully correct I think we should not be raising OCE at all in the 6 cases here https://github.com/dotnet/fsharp/blob/315966454bcd4e0ec273fa2ab70bcbc48cdbcb86/vsintegration/src/FSharp.Editor/LanguageService/WorkspaceExtensions.fs

Because VS does not expect us to be canceling anything by ourselves. Hence this pops up here and in telemetry.

But rather as @T-Gro suggested we should raise some custom exception and then handle it everywhere (replacing with some kind of empty result/no-op). Unfortunately exceptions kinda go around the type system so we won't know if we covered all the places and will only find out from telemetry.

Maybe we could replace all our top-level cancellatbleTask builders by some cancellableTaskWithDefault ( ... ) that would handle this.

It sounds a little bit like a job for some asyncResult, but we probably don't want to go there 😄

[0101]

#17906 only solves a subset of this issue.