This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
This happened a while ago at one of the corporations where I wor...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Daniel, great article (and awesome cover image š)! One thing that stopped me:
I know I'm probably living in a dream world, but actually this is what should happen every time when testing a new feature. How did it look in your case? You did not have QAs test the feature? Or did nobody consider such a case? Now that I think about it, I probably wouldn't think of opening so many tabs š¤ Interesting.
Thanks! I hope I understood your question correctly. š
The feature was tested by our QAs, but this particular case was not discovered before the release. It required multiple tabs to refresh their tokens at just the right or wrong time, so it was an intermittent race condition rather than a consistently reproducible scenario.
One tab refreshed the token and invalidated the previous refresh token, while another tab was still trying to use it. The bigger problem was that the shared frontend library could not recover from the resulting 403 Forbidden response and left that tab completely stuck.
So yes, opening the application in multiple tabs was considered a normal use case, but nobody anticipated this exact token-refresh race condition during the original testing. Even after we identified it, the team maintaining the shared library was unable to reproduce it.. š
When I reimplemented the authentication flow(as part of the bug fix š), it went through QA again. They tested the original scenario directly, but the fix was also exercised indirectly during other test cases where opening multiple tabs was part of the testing process.
Ah, I see now. Thank you for the explanation. So tricky! š
Hahaha, that's a beautiful story! š¤£ Corporate "helpful" shared services at their finest.
We have something very similar in my company, too. The only difference is that ours isn't a collection of separate building blocks, but it's one huge framework. š
The people maintaining it seem to believe nobody will ever have to upgrade it, because every new version comes with breaking changes as if there were no tomorrow. They'll rename classes, methods... sometimes something goes from close() to closeDialog(), only to become close() again two versions later. Truly groundbreaking changes. š
At this point, the more we work around it and build our own implementations where it makes sense, the healthier our project tends to be. š
Thanks!
Thatās hilarious. š It looks like the lifecycle of these āhelpfulā shared services is the same in every corporation.š
Sometimes I feel like the maintainers develop these libraries mainly for their own test applications. At first, every team tries to use them to save time, but after enough struggles, many teams just reimplement the features themselves. Constant breaking changes combined with little willingness to fix bugs is just... corporate life. š
Good Luckļ¼
You mean good luck surviving the ridiculousness of corporate life? š
Haha, speaking as a QA, you're exactly my kind of developer.And good luck with DEV's Summer Bug Smash: Smash Stories ā hope you bring it home! š
Oh, thanks! ā¤ļø But I suppose there will be much better submissions. I did not really think of this as a winning one. It was just one of the āfunnyā stories I have from fixing bugs in the corporate world. š
The world is tattered and torn, but there's always someone quietly stitching it back together.
Here's to everyone who gives more than they take.š
The cover image looks good! haha
Agree! šÆ Looks awesome! š
Thanks to both of you @technogamerz, @klaudiagrz ! I played around with it a lot. Did you notice the LOTR theme? š Especially the hobbit and Smaug. š
Ahahah, that was my guess! š It gives LOTR or WoW vibes!
You have an excellent eye! š® Iām pretty sure my first prompt included both LOTR and WoW (World of Warcraft). Iām a big fan of both btw. š
I spent so much time on both that my eye couldn't have missed it š Damn, now I have the mood to play WoW again š„¹
Great topic! Shared auth libraries are such a critical single point of failure. Iām curious ā was this bug related to edge cases in token validation or race conditions?
Thanks! It was a race condition in the token refresh flow. One tab refreshed the token and invalidated the previous refresh token while another tab was still trying to use it. The shared authentication library then failed to recover from the resulting 403 Forbidden response.
The debugging was the easy part. The real cost was walking logs between teams that each believed the problem lived somewhere else. Coordination failure is a discovery problem in disguise, because nobody knew who actually owned the edge between the two systems. That is the situation I keep thinking about when building human discovery in Opportunity Skill. You describe the person you need in plain language, say the owner of a shared library who has fixed token race conditions, and semantic matching searches recorded profiles and impressions instead of org charts. Cross-boundary bugs mostly die of routing, not diagnosis.