[Bug]: first Android modern-bridge call can miss the reply proxy if synchronous

[richavos]

Capacitor Version

8.2.0

Other API Details

Platforms Affected

• iOS
• Android
• Web

Current Behavior

On Android's modern WebMessageListener bridge, MessageHandler dispatches the incoming message before it stores the JavaScriptReplyProxy for that message.

That means a plugin method that resolves synchronously during the first modern-bridge call can reach sendResponseMessage() while javaScriptReplyProxy is still null. When that happens, Capacitor falls back to the legacy WebView JavaScript response path instead of replying through replyProxy.postMessage(...).

This can make the first synchronous plugin call flaky: the native plugin resolves successfully, but the JavaScript caller may never receive the result if that legacy fallback path is ineffective at that moment.

Expected Behavior

The reply proxy for a modern bridge message should be available before plugin dispatch begins, so a synchronous response from the first call is always delivered through replyProxy.postMessage(...) and does not depend on the legacy fallback path.

Project Reproduction

.

Additional Information

Minimal failing conditions:

1. Android modern bridge is enabled
2. The first plugin call arrives through WebMessageListener
3. The plugin resolves synchronously
4. The JavaScript caller expects the normal modern reply path

The current listener ordering is effectively:

postMessage(message.getData());
javaScriptReplyProxy = replyProxy;

A focused Android unit test demonstrates the problem by asserting that the first synchronous modern-bridge call should use the reply proxy instead of WebView.post(...). Reordering those two lines makes that test pass.

[ionitron-bot]

This issue needs more information before it can be addressed. In particular, the reporter needs to provide a minimal sample app that demonstrates the issue. If no sample app is provided within 15 days, the issue will be closed.
Please see the Contributing Guide for how to create a Sample App.
Thanks! Ionitron 💙

[Ionitron]

It looks like this issue didn't get the information it needed, so I'll close it for now. If I made a mistake, sorry! I am just a bot.

Have a great day!
Ionitron 💙

[richavos]

@jcesarmobile is the unit test producing the failure on the linked PR not reproduction enough?

This fails intermittently for us. Our first plugin call is always synchronous ("get my context", which is known immediately by the activity). In maybe 1 in 100 runs of our app, that call is never settled.

In trying to produce a simpler reproduction case, I have a script that runs a simple app, and have seen it fail in the way described, but only twice in over 5000 runs. I'm not sure what levers to pull to increase the likelihood. Perhaps you could reverse engineer the conditions needed by looking at #8383 and working backwards - I'm not so familiar with the Android side, so I'm at a disadvantage there. But by looking at the code, I reasoned there's a gap in the behaviour, and that PR has a unit test demonstrating that a problem exists!

Our current workaround is a ping-like test, waiting until the webview gets a pong back before continuing. Obviously, this sucks, and we'd like to remove it.

(I'll ignore that the bot said I had 15 days, and it has been only 8 🥲)

[jcesarmobile]

No, a mocked test is not verification enough, we request a sample app that reproduces the issue.

Sorry about the confusion about the days to close, the policy was changed recently and we forgot to update the bot message, I've changed it now.

[richavos]

Thanks for your reply! 2 questions:

• what rate of reproduction would you consider "acceptable" for a ticket? Would supplying the logs for the time it fails, alongside the code, be enough?
• to sidestep this entirely, consider the fix I proposed in fix(android): allow synchronous replies on the modern bridge #8383 - conceptually it's a simple re-ordering of two lines (moved to a separate method to aid in writing the test). Could you/someone on your team consider if in fact the current ordering affords the bug described here, and fix directly? (This ticket be damned.)