Mini Client disconnects on any navigation

[mhmdibrahimm]

I noticed that the Mini Client disconnects everytime a new route is created. It disconnects and automatically reconnect. Recent log:

[client] client disconnected // on route navigation click
[inteceptor] AppletIndexContainer::OnLoadStart onEnter, indexContainer.this:  0x7cac049471c0
[conn] miniapp client connected

Tested on many applets, all of the same result. Notice that this behaviour doesn't happen in WeChatOpenDevTools repository (which I believe is the inspiration of this project).

Could it be fixed?

[mhmdibrahimm]

I want to note that it was also tested on many WeChat versions & WMPF versions. Same results.

[evi0s]

Interesting, in theory when the new route is created (e.g., navigateTo), the process simply creates a new iframe (page-frame-xxx) in the same tab instance where mainContext and appContext also live in together in iframes. I only tested the official example miniapp and didn’t observe that happened. Would you please provide more information so that I can locate the bug? Such as WMPF versions, logs, miniapp IDs, navigation method. Thanks for testing!

[mhmdibrahimm]

I tried it on 13341 & 11581 WMPF Versions. For mini apps IDs, I tested it on 3 mini apps and they all had the same result. So, I guess you can find this behaviour on any mini app you try. For the method, I am pretty sure it's using wx.navigateTo.

[evi0s]

Just tried these four on WMPF 13341 and everything works fine. For 11581 it's a known issue that the renderer will crash. Would you please provide logs or the exact miniapp IDs? The info you provided does not help.

[mhmdibrahimm]

Sorry for being less clear with my instructions.

WeChat 4.0.2.22 WMPF 13341 miniapp ID: wx3eaaa8406eb1120d miniapp name: 1688

Steps to replicate:

1. Run npx ts-node src/index.ts
2. Launch the mini app
3. Connect the devtools on your browser
4. Click on any item

6. Observe in the console:

[client] client disconnected
[inteceptor] AppletIndexContainer::OnLoadStart onEnter, indexContainer.this:  0xd2004a27840
[conn] miniapp client connected

It Disconnects and then reconnect directly after navigation

Full log: log.txt

[evi0s]

Thanks for the detailed info; I can reproduce this issue now. It looks indeed very weird but the developer tool doesn't actually disconnect with the miniapp (or, the tool disconnected but the session is still alive and it picks up when the miniapp reconnect) and everything still works. Would you mind explain any concerns that this will affect any debugging or integrating? I'll look into it further when I have time.

I can also observe that multiple iframes (id="page-1xx") were created due to the navigation shown below. The preview is indeed not changing, which may be the reason of instrumenting that causes preview delays. You can see my preview is even stuck at the half way and the Protocol Monitor also doesn't show any preview update requests.

[mhmdibrahimm]

Some requests in the network tab do not show due to this reconnection. Another concern is code execution in the console, if their is any promise pending and the navigation occurs then the client disconnects, the promise can't be resolved/retrieved.

I really appreciate your work.

[evi0s]

You're right. In theory it could happen. I'll take a look.

For network and console however, I can confirm it's still working, at least in the rather simple scenario, you can check it below. Whenever a new iframe is created with WAWebView loaded (i.e., navigating to a new page), the console will print WeChatLib: 3.6.6 (2025.1.17 18:07:42), indicating the navigation has been made and the new page is loaded, and you can see the promise has still resolved with values.

[mhmdibrahimm]

I can confirm that their is some missing requests. I will give you some steps for reproduction:

WeChat 4.0.2.22 WMPF 13341 miniapp ID: wx32540bd863b27570 miniapp name: 拼多多

Steps to replicate

1. Open the mini app:
2. Run npx ts-node src/index.ts
3. Launch the mini app
4. Connect the devtools on your browser
5. Click on any item

The request for the goods Id has the following URL: https://api.pinduoduo.com/api/oak/integration/render Check the network tab in your dev tools, search for render, nothing will show

Proof of existance:

1. Go to the console tab
2. Run the following command to hook to XMLHttpRequest and stop the app when this endpoint is called

  const originalOpen = XMLHttpRequest.prototype.open;
  XMLHttpRequest.prototype.open = function(method, url, async, user, password) {
    // Check if the URL matches specific target
    if (url.includes('render')) {
      debugger; // This will pause execution when the condition is met
    }
    // Call the original open method with the original arguments
    return originalOpen.apply(this, arguments);
  };

4. Go back to the main page in the mini app, open any item again, debugger is not called.
5. Now, turn off the wifi network on your pc
6. Go back to the main page in the mini app, open any item again, debugger is called and method is shown in the network tab.

Explanation: When the client is reconnecting, this request --along with many others-- is lost. When your wifi network is turned off, the mini app doesn't call this method directly after navigating, with that said, it is not executed in the disconnection/connection phase so it shows.

Further debugging: You can check WeChatOpenDevTools dev tools. On the same mini app, the request shows in the network tab. Explanation: These dev tools do not connect through remote debugging so their is not any disconnection.

[evi0s]

Thank you so much for the detailed reproduction steps. I have looked into your case that missing network logs; the reason for that is because Pinduoduo wrapped those requests into a WebSocket naming titanSocket. You can find the screenshot attached below. If you open the network tab and look into the wss://titan-ws.pinduoduo.com/, you can find your requests went through there.

[mhmdibrahimm]

Thank you for replying,

while your explanation that Pdd wraps the requests into the titanSocket, it doesn't fully account for all observed behaviors. Specifically:

• In the normal (non-remote-debugging) dev tools, the request does appear in the network tab as expected. If the wrapping by the titanSocket were the answer, we would expect a consistent absence of the request across all dev tools.

• The request only shows up when we insert a debugger—essentially delaying the execution—allowing the request to complete before the disconnect-reconnect cycle. This indicates that the timing of the connection drop is interfering with the request logging rather than it being exclusively rerouted via WebSocket.

The titanSocket is for logging and risk control, and requests appear under normal circumstances and only disappears during disconnection/reconnection, which suggests that the network interruption itself is causing the loss of network logs. This behavior points to a timing issue in the disconnect-reconnect cycle rather than a deliberate rerouting of the request.

[mhmdibrahimm]

I will look into this tomorrow, your theory might be right. Thank you anyways!

[evi0s]

Interesting, I agree that remote-debugging may trigger some weird or unknown behaviors which fundamentally it is different from the embedded devtools. Maybe take a look in to the embedded devtools on how those requests are handled? I don't have the lower versions so you might need to do it on your own.

For the titanSocket, from the code I believe as long as the socket instance is alive, that request will go thought it because of the if statement I've attached before, and the reqType is hardcoded to sh_api_socket shown below:

Also, you may have noticed there're some requests (including https://api.pinduoduo.com/api/oak/integration/render) appeared in the network tab in my previous comment that should go through the websocket, I'm guessing there're some code such as socket timeout for resending requests?

Or, maybe some simpler cases for reproducing the connecting-disconnecting timing issue?

[mhmdibrahimm]

I will close this for now as I got a workaround. Feel free to open it again.

[evi0s]

I’ve narrow down the issue to the debug message channels that the server didn’t respond to some messages that miniapp clients sent, causing the miniapp trying to reconnect. Due to the large amount of messages I’m still trying to figure out which exact message caused that, will update it when I have time. Thanks again!

[mhmdibrahimm]

Oh, interesting, I am waiting for your updates.

Thank you.