"While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit when toLocaleString worked on iOS and but only worked on Android while debugging. It turns out that the Android JSC doesn’t include it and it was silently failing unless you were debugging in which case it was using V8 which does."
Wow, I can't imagine how frustrating this must have been to debug.
I ran into a fun one like that many years ago in IE. The JavaScript I had written was failing, but when I opened up the devtools to debug it, it worked.
It turned out that in that version of IE, the console object only existed when the devtools were open. So a stray console.log call was causing an exception because console was undefined. But when I opened the devtools to see what was going on, console existed and so everything ran just fine.
I suppose that's the kind of error that only bites you once. When you know about it, you tend to never make that mistake again. But that first time you run into it can cause a painful few hours of head scratching and attempted debugging.
Funnily enough, I ran into a React Native error like the one described in the article, where something worked only while debugging. My previous experience with the heisenbug in IE led me to immediately dig into what was different in RN with the devtools open vs without them. So in a way, those hours I wasted in IE back in 2010 prevented me from potentially wasting hours debugging RN in 2017.
I had a bug that was even worse, and I never found a workaround for IE11.
In this case I had some kind of progress bar that was updated while a report is being generated. When the report is completely generated, the progress bar is replaced by a button.
Except in IE11. At some point the progress bar stopped updating and it never turned into a button. Until you opened the developer tools and IE11 "flushes" the DOM and paints the new situation. So, never having found the cause, we recommended that (internal) customer to use F12 regularly on that page.
"It turned out that in that version of IE, the console object only existed when the devtools were open. So a stray console.log call was causing an exception because console was undefined. But when I opened the devtools to see what was going on, console existed and so everything ran just fine."
Modern SOAP doesn't sound too bad to me! But then again, I never found SOAP to be all that bad.
I might have been lucky, though. Every time I had to use SOAP, it was just a matter of auto generating a client interface in whatever language I happened to be working in and then proceeding from there. I suppose not everyone was so fortunate.
I found that autogeneration rarely worked well unless the client and the server were using the same tooling.
The monstrous flexibility of xml and soap meant that in practice every soap server interface I had to consume had some quirk or incompatibility with the client I was trying to use.
I had something like that once in native web dev. It turned out that by default when using the debugging pane the browser would disable cache so the issue (whatever it was) disappeared.
And, annoyingly, if you check the disable box any time you close the dev tools it resets to unchecked. If you reopen dev tools it still remains unchecked.
What version of Chrome did you experience this in? I've never had to re-check the "disable cache" checkbox, even after restarting chrome from a crash state. I am currently at version 67.0.3396.87
I was dealing with a similar bug yesterday. I was using Python (Pyramid/SQLAlchemy/PostgreSQL) and had an integration test that was failing about 80% of the time, but would never fail when I stepped through the test code.
I ended up pairing with another developer, who rewrote the test from scratch and didn't have the issue. I think I know what the problem was, though - the test code called the route in question on one line, then the next line retrieved an object that was modified during the request. The line after that asserted that an attribute of that object had been changed. Most of the time, it hadn't changed; sometimes it had. To make matters work, any time the file was modified it seemed to work once or twice then begin failing again.
I'm 99% sure what was happening is that by the time the object retrieval happened in the test code, PostgreSQL hadn't fully committed the changes to the DB that were made during the request and the object returned was unmodified. Why was that happening? No idea. I suspect it was something to do with connection pooling or the way we were using gevent monkeypatching elsewhere, even though the tests themselves weren't using gevent.
Things like this are both the most frustrating and most fulfilling part of development :)
Thanks for pointing this out. This part was my experience and as you said, it was quite frustrating. Overall the RN experience made me more skeptical about thing I usually take for granted.
It really shows how hard it is for RN to work cross platform. Each abstraction layer can bring in some new problems.
IIRC the whole debugging took half a day. There wasn't exactly an Aha moment either. Enough trying different accounts/platforms/devices/environments made me realize that debugger might have changed the result. Once it was confirmed I actually felt defeated. Hard to feel good when you are hit by observer effect and at the same time realize that the a native JS API could be problematic.
Wow, I can't imagine how frustrating this must have been to debug.