I Saw An Extremely Subtle Bug Today And I Just Have To Tell Someone

While reading this article, it reminded me of an odd bug I encountered working with the Nitrogen Web Framework. I was finding that, similar to Patrick, it was losing sessions (though much more consistently), but only in Chrome and only with Yaws as the webserver. Switching to the Mochiweb server or Firefox caused the problem to go away.

Firebug and Chrome's dev tools both reliably stated that the cookie header was indeed being set. I just didn't know why Firefox was accepting the cookies and holding the sessions, but Chrome was dropping the sessions.

Oddly, it was only happening on my virtualbox dev environment, and not on any production machines.

After much time, I noticed that the expiration date for the cookie was in the past. I hadn't noticed it before because it looked right (it correctly passed my mental regex for "looks like a good date").

It turned out the problem was being caused by my machine going to sleep, pausing everything (including the clock timer in the VirtualBox instance, which I leave on for weeks or months), causing the clock on the virtual server to get behind by several days.

Then, when setting the cookie expiry date in max-age format, rather than absolute time, Mochiweb would send the Max-age expiration, which then gets handled by the browser relative to the receiving time. But Yaws would first take server time, add the seconds, and send that as the absolute expiration, effectively sending an past date to the browser as the expiration.

Firefox, apparently, saw the cookie expiration date, and just said something like "Hey, we'll hold this until the user closes the tab or something", while chrome saw the expired cookie, and immediately expired it, appropriately.

That's one of the weirdest non-bug bugs I've encountered.

Note: when I say "Yaws" and "Mochiweb", I mean "Nitrogen's SimpleBridge connector for Yaws and Mochiweb".

Habitually taking responsibility for things outside your control is probably a bad thing though.

Perhaps you should have constructed an API, and tell them "This is what your code should abide to", instead of just giving them code for the button. That is: abstract the spec away from the actual code.

If closer inspection shows that their code isn't following the spec, you've earned the right for some serious fingerpointing.

This is very much not the cultural norm over in these parts. I'd be curious to hear your reason as to why you think that. (Genuinely curious, not passive-aggressive "curious.")

Particularly with specific regards to engineering, even things which are theoretically not within our control (e.g. the server going down because a technician tripped over the cable) are often inside our ability to affect (by picking a better provider, investing in a redundant setup, etc). This is good: after we know that things are generally within our capabilities to address, we'll address them, rather than thinking that it is outside the scope of our responsibility, capability, or authority.

(Semi-related sidenote: For hackers who enjoy theology there is a doctrine in Catholicism called subsidiarity which, as a quick gloss, states that responsibility for solving a problem begins immediately local to the problem and then bubbles up to the lowest level of societal organization which is capable of resolving that problem. That level is obligated to solve the problem rather than passing the buck up, where it will not receive sufficient attention, or down, where it will not receive sufficient resources.

I always thought, aside from being a good idea, this was virtually tailor made for programmers. It's like there is a papal encyclical on the canonical right way to do exception handling.)

I think there are two factors. Clients want solutions, not excuses and they can often do without explanations. So, taking responsibility to solve a problem will (generally speaking, on average, etc) work in your favour if you have remotely appreciative clients.

However, beating yourself up over it is best avoided.