Cannot Register URI Handler in Activation Event

[tsmaeder]

Bug Description:

In the context of #13306, I have implemented the onUri activation event. The logical thing to do in response to this event is to register a uri handler. However, this does not work because the activation finishes for the front end before the uri handler registration call is invoked.

Steps to Reproduce:

1. Install the extension from the referenced PR
2. Add the "onUri" activation event to its package.json
3. Run Theia
4. Open the uri theia://tylerleonhardt.open-external in the OS (in the browser, for eample)
5. Observe: there is no message being shown by Theia
6. Open the same uri again
7. Observe: you get a message saying the uri has been handled by the plugin

Additional Information

• Operating System: Windows
• Theia Version: Implement previously stubbed window#registerURIhandler (#13169) #13306

[tsmaeder]

In uri-main.ts, we have this code:

           canHandle: async (uri: URI, options?: OpenerOptions | undefined): Promise<number>  => {
                if (uri.scheme !== FrontendApplicationConfigProvider.get().electron.uriScheme) {
                    return 0;
                }
                await this.pluginSupport.activateByUri(uri.scheme, uri.authority);
                if (this.handlers.has(uri.authority)) {
 ...
async $registerUriHandler(pluginId: string, extensionDisplayName: string): Promise<void> {
        this.handlers.add(pluginId);
    }

When the call to activateBytUri() returns, we would expect $registerUriHandler() to have been invoked, but it hasn't.

[tsmaeder]

The theory is this: when we first get a proxy to invoke $registerUriHandler(), the queueing of the message is delayed by the rpcDeferred and the proxySynchronizer in the plugin-ext/.../proxy-handler.ts. Since the reply message to the inital activation sees no such delay, it will get sent immediately, thus overtaking the registerUriHandler() request. The $registerUriHandler()call cannot be awaited because it is part of the non-async VS Code API vscode.window.registerUriHandler().

[tsmaeder]

Reordering message is generally a bad idea, as it leads to hard-to-understand issues like the one addressed in #13180.
An approach would be to not rely on the promise resolution queue, but instead to have an explicit queue of message sends. Whenever a message send is delayed, all message sends enqueued after that one will have to wait as well.

[tsmaeder]

I suspect we also have a problem at initialization time: when we open multiplexed channels from the plugins side, the routing on the client side (hosted-plugin-watcher.ts) does not seem to be in place yet (no listener added). Thus, we never acknowledge the opening of the channel. Not sure if this is an artifact of my attempts to fix this bug, though...just writing it down for the record.

[tsmaeder]

Unfortunately, this is an instance of a very deep-seated problem: when we start up a plugin host, we immediately set up the plugin API, which in turn (as part of @PostConstruct) opens multiplexed Channels for the service proxies it refers to. That happens before the client-side RPC protocol for the plugins host has been set up, therefore the "open channel" messages for "main" proxies simply get lost.

I have reported similar problems before in #8429 and attempted a fix in #8437. Unfortunately, I was unable to get anyone to review the PR at the time.

[tsmaeder]

Actually, there are two different issues at play here:

1. The establishment of a channel from each plugin host (webworker, backend, plugin-host process) to the API RPC counterpart in the front end before any messages are sent to the front end (which initializes later, typically)
2. The initialization or RPC instances in two phases: if we call a remote method before the receiving side RPC handle of the proxy has been set, the message will be discarded. So we need to make sure both sides of the rpc protocol have initialized their receiving sides before being able to make calls across the RPCProtocol

[tsmaeder]

Turns out we solve all this by not relying on multiplexed channel for routing to different service instances, but instead the RPCProtocol instance using a single channel and routing to handlers itself. It completely removes the need for waiting for subchannels to be opened and we can remove all the synchronisation infrastructure as well while preserving the invocation order. It's how things worked before the last refactoring of this code.