[DevTools Bug] Unsupported Bridge operation "0" #23307
Comments
gitrthanki1
added
Component: Developer Tools
Status: Unconfirmed
|
Wtf |
|
Facing same issue The error was thrown at file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5441:339974
at kr.emit (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5441:281413)
at file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5441:283045
at file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5441:688182
at Array.forEach (<anonymous>)
at A.oe.onmessage (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5441:688165)
at A.t (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5432:3330)
at A.emit (events.js:315:20)
at oe.exports.L (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5396:14736)
at oe.exports.emit (events.js:315:20)
at oe.exports.dataMessage (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5396:21208)
at oe.exports.getData (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5396:20405)
at oe.exports.startLoop (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5396:17712)
at oe.exports._write (file:///Applications/Flipper.app/Contents/Resources/app.asar/bundle.js:5396:17002)
at doWrite (_stream_writable.js:403:12)
at writeOrBuffer (_stream_writable.js:387:5)I even tried toggling the "Use globally installed DevTools" and I have devtools installed globally but it didnt work |
|
Same issue here as well. |
|
Hi, thanks everyone for commenting! Are any of you experiencing this issue with the most recent release of DevTools? If so, could you provide a codesandbox or a github repro? Unfortunately, we're not able to debug this issue without proper repro steps. Thanks! |
|
I can confirm replicating this on a vanilla react-native app using flipper (where I believe this issue was created from), the issue also persists on 4.22 as well as 4.23, however using ❯ npm i -g [email protected] sorts the issue for me
|
|
Hey! I just created a vanilla react native app using create-react-native app and tested React DevTools, and I couldn't repro the error. Could you give me an exact repro? |
|
I ran into the same issue on a new React Native 0.67.3 app generated with Clicking dismiss on the Unsupported Bridge operation "0" message removes that message but then I am presented with this error:
I checked which version of react-devtools-core that the Metro server is using: So React Native uses react-devtools-core 4.19.1, not too far behind the latest. So it should be compatible right? Well by downgrading to use the exact version that React Native uses, it is now working for me. So I guess 4.19.1 and 4.23.0 are not compatible |
No. This is why the dialog suggests downgrading the frontend. We know this is not ideal, but the architecture of react-devtools and react-native has been around for a long time (predating those of us now working on the tooling side). For the browser extensions (most common use case) or even packages like
That's correct. |
|
The dialog suggests downgrading to a version prior to v4.11.0, but because the backend is running 4.19.1, following the directions in the dialog does not work. We are presented with a similar message, but instead the dialog suggests upgrading to
With the given semver notation, version 4.23.0 satisfies It looks like the backend of 4.19.1 (presumably using bridge protocol version 1) communicates an incorrect bridge protocol version. Either that or the frontend of 4.23.0, which expects version 2, reads an incorrect bridge protocol version from the backend. Ether way, the dialog suggests a misleading downgrade command. At any rate, the main point is if you're getting either Unsupported Bridge operation "0" or Unsupported DevTools backend version, check the backend version you're using (which, with React Native, it's currently 4.19.1) and make sure you have that exact version of the frontend. |
|
The dialog's suggestion is based on which version of the backend React Native has embedded. If the frontend version you are currently using requires a newer protocol, you will be prompted to downgrade (to match). If the frontend version requires an older protocol version, you will be required to upgrade (to match). At least, that is how it is supposed to work. Given this issue, it sounds like some combination(s) of backend and frontend version aren't working as designed. @DrOverbuild Any chance you could give me a list of exactly which versions (backend and frontend) you used that showed that series of dialogs? I'd like to repro and dig into where things went wrong. |
|
With not being able to respond due to the lockdown last week, I had some extra time to investigate the issue.
To answer your question, the only backend I've tried is 4.19.1, bundled with React Native.
Looking at source code I see the front end assumes bridge protocol version 0 if it doesn't get a response within 10 seconds (because old versions of DevTools don't know about bridge protocol versioning). This timeout is further confirmed by the fact that I'm getting that downgrade message only after 10 seconds of staring at a blank inspector. However, the manner through which I get the RN app to connect to devtools matters. If the app is already running and I open the debug menu in the RN app, devtools will timeout. If I terminate the app and run it again, devtools will timeout. But if I just reload the app, devtools does not timeout and shows that the backend is using bridge protocol 1. I want to say this is more an issue with react-devtools-core in React Native than with the frontend. |
|
Thank you for the extra context!
This seems broken. I'm guessing the timeout is firing when it shouldn't, maybe b'c something isn't forwarding the protocol check message (or not forwarding it fast enough?) |
|
Ok I downloaded this entire repo and set up a dev environment so I could debug what's going on here. We're getting When that happens, I added a console.log here, and this is the output when connecting with an unsupported back end version: The bridge receives no message after processing the After commenting out the throw statement here we see Again I didn't have enough time this afternoon to investigate how errors are handled above the event emitter. Are you intentionally ignoring incoming bridge messages after an error like this happens? Either way I think the root of this problem is incomplete error handling or simply timing of the bridge messages. |
|
This is helpful! Thank you. So the repro steps basically sound like...
Is that right? Let me see if I can repro too. Edit 1 – I can repro. |
|
Yes it's happening with DevTools frontend versions 4.22.1 and up. As far as the backend goes, I'm only able to reproduce this in React Native. I couldn't reproduce it in a web app. But maybe I'm not setting it up correctly? I tried adding DevTools core to a create-react-app template, and calling connectToDevTools() before importing react and react-dom, but I see that the frontend never actually gets any |
Right, that makes sense, because the backend and frontend are bundled along with each other in the case of the web extension and inline packages. Even with the standalone, the webpage loads the backend script via an HTTP server the frontend runs. React Native is the odd one out. |
|
As a workaround for anyone reading this, you could use an approach like Resolutions to work around the backend version mismatch, e.g. "resolutions": {
"react-native/react-devtools-core": "4.24.0"
},I used a similar resolution in my test React Native project to force downgrade the backend to 4.19.1. |
|
Okay, after digging into this– I can repro it. I'm not sure there's a great workaround or "fix" for it though. The underlying issue (explained in #21326) still needs to be handled. Maybe React Native could do a better job of prompting/matching backend and frontend versions during installation? I'm not sure how React DevTools (the frontend UI) could do this other than via some protocol version check like we are already doing. (Although if anyone has ideas I'd love to talk about them.) In hindsight, I should have made the very first parameter in the operations array a protocol version number. Then the frontend could treat messages different based on their known protocol. But it's too late to make this change and so here we are. |
|
Looking at the history of the Bridge protocol stuff, we basically have the following changes:
The source revisions for the above versions are: Exporting and comparing these revisions... # Export
git archive -o ~/Desktop/DevTools/4.10.1.zip f160547f47cb271bff09c639a6dae8f1b169bc14
git archive -o ~/Desktop/DevTools/4.11.0.zip d4cae99f2a59e0380871134960d29ec5ce2c4fd9
git archive -o ~/Desktop/DevTools/4.21.0.zip 6c7ef3fce5547da5db3d400ccf95a5023f8891f4
git archive -o ~/Desktop/DevTools/4.22.0.zip 0229baee21e8e6ecef04d4d76c41af84dfcca8bc
# Extract...
# Diff:
diff \
./4.10.1/packages/react-devtools-shared/src/devtools/store.js \
./4.11.0/packages/react-devtools-shared/src/devtools/store.js \
> 4.11.diff
diff \
./4.11.0/packages/react-devtools-shared/src/devtools/store.js \
./4.21.0/packages/react-devtools-shared/src/devtools/store.js \
> 4.21.diff
diff \
./4.21.0/packages/react-devtools-shared/src/devtools/store.js \
./4.22.0/packages/react-devtools-shared/src/devtools/store.js \
> 4.22.diffLooking at the store diffs, I see the following changes between protocol changes::
If I had thought to design the operations array up front to include its protocol version as the first bit, then we could easily support backwards compatability in cases like this. Really bad oversight on my part, in hindsight. As it is now, we could try to do this (if we already have the protocol version) but there would be cases we can't handle (e.g. the backend is too old to report its protocol and the frontend times out). Maybe we could queue up operations until we know (or infer) the backend version? I'm not sure how hard this would be to implement in practice, especially when considering cases like reload and profile. Probably hard. I'm not sure there's really a way to fix it at this point. If I could go back, unpublish and overwrite each of the older revisions to add this info, maybe...but NPM doesn't support that kind of an operation. |
… for old protocol operations format (#24093) Rationale: The only case where the unsupported dialog really matters is React Naive. That's the case where the frontend and backend versions are most likely to mismatch. In React Native, the backend is likely to send the bridge protocol version before sending operations– since the agent does this proactively during initialization. I've tested the React Native starter app– after forcefully downgrading the backend version to 4.19.1 (see #23307 (comment)) and verified that this change "fixes" things. Not only does DevTools no longer throw an error that causes the UI to be hidden– it works (meaning that the Components tree can be inspected and interacted with).
|
@bvaughn can I just check for Flipper. Does it mean, we can only use the latest
Update: |
|
@usrbowe Bumping the version of the React DevTools (frontend) used in Flipper sounds like a good idea. 4.24.1 is more "compatible" with older backend versions. |
Summary: Related to this issue: facebook/react#23307 ## Changelog bump react-devtools-core to 4.24.1 Pull Request resolved: #3542 Test Plan: // bvaughn Reviewed By: passy Differential Revision: D35211366 Pulled By: mweststrate fbshipit-source-id: 890d18e87ba07e140c1c49857d02410767c6c17d
… for old protocol operations format (facebook#24093) Rationale: The only case where the unsupported dialog really matters is React Naive. That's the case where the frontend and backend versions are most likely to mismatch. In React Native, the backend is likely to send the bridge protocol version before sending operations– since the agent does this proactively during initialization. I've tested the React Native starter app– after forcefully downgrading the backend version to 4.19.1 (see facebook#23307 (comment)) and verified that this change "fixes" things. Not only does DevTools no longer throw an error that causes the UI to be hidden– it works (meaning that the Components tree can be inspected and interacted with).
|
|
|
|
I had the same issue, downgrading to 12.1 worked for me. |
and others
Website or app
local app development
Repro steps
just install react devtools and downgrade to 4.11.0
How often does this bug happen?
Every time
DevTools package (automated)
react-devtools-core
DevTools version (automated)
4.23.0-e28a0db22
Error message (automated)
Unsupported Bridge operation "0"
Error call stack (automated)
Error component stack (automated)
No response
GitHub query string (automated)
The text was updated successfully, but these errors were encountered: