Wow, I can't imagine how frustrating this must have been to debug.
Wow, I can't imagine how frustrating this must have been to debug.
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.
In older Android versions, warnings in modern versions actually crash React Native apps. Can be very frustrating.
Flashbacks commencing.
gRPC is just a modern SOAP. There, I said it.
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.
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.
The worst offender was security extensions.
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.
Close debugging? It broke again.
Maddening.
That has to be the strangest combination of terms I've seen this month.
What was your point again?
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 :)
It really shows how hard it is for RN to work cross platform. Each abstraction layer can bring in some new problems.
How long did it take for the Aha! moment?
(or vice versa? i forget)