Code Editor 2: Feather's "Rename Identifier Recommendation" tool does not work

[MangoB1]

Description

Feather's "Rename Identifier Recommendation" feature for a GM2017 rule does not do anything in CE2. I click it and then the variable in question doesn't change at all. It works when I use CE1.

Bug package upload is throwing me an error. Can provide when it's fixed

Expected Change

The variable in question gets renamed to the recommended format

Steps To Reproduce

1. Start GameMaker
2. Navigate to a GM2017 error.
3. Click the Feather icon on a row that has my error and select Rename Identifier Recommendation.
4. See the issue

How reliably can you recreate this issue using your steps above?

Always

Which version of GameMaker are you reporting this issue for?

2024.11.0 (Monthly), 2024.1300 (Betas)

Which operating system(s) are you seeing the problem on?

No response

Are you running GameMaker from inside your Steam library?

None

Sample Package Attached?

• I have attached my bug package

Sample Project Added?

• I have included a small sample project

[zreedy]

Related to #10689

[zreedy]

Fixed. There was a deadlock related to dispatching a WorkProgressObserver event from the Server to Client.

FOR QA
Any operation which might have shown a progress bar in the top right could have deadlocked the server this includes: Adding or Deleted Assets, Adding or Deleting objects in a Room, Renaming an Asset, Reanalyzing a Project, or applying any Refactoring operation (as noted in this ticket). All of these operations should be checked to ensure there is no loss to the language services.

FOR DEVELOPERS
OmniSharp Entry Points are async Tasks, most of the Feather Logic Layer is synchronous code called into from the async entry point. This means that an async context is retained for the lifetime of the call but any async calls in the logic layer must be synchronously completed. The OmniSharp call to dispatch a ProgressEvent is async, forced to complete syncly via .Result on the returned Task. This Task will initialize as AwaitingActivation as it expects to be included in the current async context. This is not possible because we're within a synchonous block and thus deadlock waiting for the sync block to finish before the async block can be syncly executed.

The solution was to offload the async code to a new background thread and dispatch via a concurrent queue and semaphore. The task is still forced to complete syncly here (though it could be async I suppose but we'd need to rework the bg thread to a bg task which comes with its own complications), but the async context is going to be different as the entry point is rooted in a different thread so the TPL scheduler assigns it a new ID.