We tried out using Haul in the branch: https://github.com/wordpress-mobile/gutenberg-mobile/tree/try/haul-next-plugins
And couldn't manage to get proper stack traces when there's a crash on Javascript side.
Without the debugger attached, it looks like the stack trace has no info at all since it鈥檚 coming from evaluated code, just [native code]: 0 all over the place:

With the debugger attached, it points to index.bundle but it doesn鈥檛 symbolicate either:

Steps to reproduce:
cd to gutenberg-mobile repo
run yarn install to install dependencies
run PACKAGER=haul yarn start to start the server(if you don't put PACKAGER=haul it'll default to Metro)
run either yarn ios or yarn android to open the example app
You should see the Hello World plugin available in the block picker at this point:


To debug the local copy of the hello world plugin clone the repo and cd to its directory
run npm install, npm run start< this will make webpack listen to changes and build instantly
run yarn link to register the dependency to your local machine
and then cd to the gutenberg-mobile path run yarn link @wordpress-mobile/gutenberg-plugin-hello-world
This should make the project see the local copy.
Then go to the onChangeContent function and put this line in it:
throw new Error( '馃檴 I crashed!');
Add a Hello World block to the post and type anything, It'll generate the crash.
Hello, the problem exists in method canLoadImageURL
Image loader has higher priority than others so if method canHandleRequest returns true the Networking will use this class to make a request, if not it will go through others loaders to find correct one. The CustomImageLoader class returns true if URL is not a file URL, which is wrong, because this loader will be used for every api call.
It also affects Metro symbolicate because the original stacktrace has to be send in body param called stack, but in GET method we can not add body params (AFAIK it is possible but is not handled by server). Because of that metro tries to call JSON.parse on empty string -
https://github.com/facebook/metro/blob/master/packages/metro/src/Server.js#L956
Conclusion: The canLoadImageURL method in CustomImageLoader needs to be reimplemented to handle only requests for images.
How did we get into the conclusion?
We started using local haul instead of one from NPM. Then we've connected Node debugger to Haul process by running the command NODE_INSPECTOR=wait yarn haul start. You can read more about it on the next documentation
Next step was to attach a debugger to Haul with the following configuration:
{
"type": "node",
"request": "attach",
"name": "Attach",
"port": 9229
}
That allowed us to discover that POST /symbolicate handler in the server is not fired. Instead, it turned out that GET is called. The crucial information was to find a source of called method and confirm if this is POST or GET.
At this point, we were sure that the next step should be diving into the native side. However, before that we wanted to confirm if this is not a platform issue. We ran exactly the same configuration on Android and discovered that everything is working as expected.
Finally, we dived into the iOS native side, more precisely to Networking implementation.
The request which was sent to native seems to have a correct method and payload so we were closer to the first conclusion - something has to be wrong with the native implementation.
We get through the native code with the debugger and found that it tries to load symbols with ImageLoader. Deeper investigation showed that the problem exists in custom image loader which is used to make this API call (check the comment above).
thanks a lot @dratwas @lukewalczak !
I'll close this issue as it looks like we have now enough insight to address it on gutenberg-mobile repo.
According to above there was also SyntaxError from Metro after crash gutenberg-mobile app using @koke crash button.
See below code:
SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at Promise.resolve.then.body (/Users/jakubbinda/GUTENBERG/gutenberg-mobile/node_modules/@react-native-community/cli/node_modules/metro/src/Server.js:1183:28)
::1 - - [31/Jul/2019:11:18:47 +0000] "GET /symbolicate HTTP/1.1" 500 - "-" "gutenberg/1 CFNetwork/978.0.7 Darwin/18.6.0"
Most helpful comment
Hello, the problem exists in method canLoadImageURL
Image loader has higher priority than others so if method
canHandleRequestreturns true the Networking will use this class to make a request, if not it will go through others loaders to find correct one. TheCustomImageLoaderclass returns true if URL is not a file URL, which is wrong, because this loader will be used for every api call.It also affects Metro symbolicate because the original stacktrace has to be send in body param called
stack, but inGETmethod we can not add body params (AFAIK it is possible but is not handled by server). Because of that metro tries to callJSON.parseon empty string -https://github.com/facebook/metro/blob/master/packages/metro/src/Server.js#L956
Conclusion: The
canLoadImageURLmethod inCustomImageLoaderneeds to be reimplemented to handle only requests for images.