Skip to content

Distracting and not helpful error toast in VS on OperationCanceled #17887

Description

@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.

Image


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.

Activity

  1. added this to the Backlog milestone on Oct 16, 2024
  2. changed the title [-]The brown eror bar just hinders my work and is never ever helpful for me.[/-] [+]Distracting and not helpful error toast in VS on `OperationCanceled`[/+] on Oct 16, 2024
  3. added
    Area-VS-EditorVS editor support for F# code, not covered elsewhere
    on Oct 16, 2024
  4. T-Gro commented on Oct 17, 2024

    @T-Gro
    Member

    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.
  5. vzarytovskii commented on Oct 17, 2024

    @vzarytovskii
    Member

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

  6. 0101 commented on Oct 22, 2024

    @0101
    Contributor

    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 😄

  7. 0101 commented on Oct 23, 2024

    @0101
    Contributor

    #17906 only solves a subset of this issue.

  8. reopened this on Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions