I was refactoring a 4000 lines JavaScript file, turning whatever I could into components. It was a pretty old project that I ended up being one of the few wizards to actually know how most of it works.

At one point, I noticed that login into a user account redirected us to the dev-test server, even when working on a local Docker container.

I never quite understood the issue, but ended up having the bug mysteriously disappear.

Until it came back two months later, then disappeared again.

At one point, all of the dev team on the project (four developers, me included, and one project manager) was investigating the issue, and we never figured out how or why this was happening.

Just Symfony routes shenanigans I guess.

🤔 nice story but: Craziest bug you ever FIXED....

@hjk101 I mean I did fix it multiple times, I just don't know how 👀

Magic Cache or some shits like that.

@wasabi nice try but that's unfortunately not really how that works 🤣. If the conditions are not met to trigger the bug it does not mean that it is not there.

Possibilities
1. Conditions have not been met. JS is event driven and that means you can have race conditions for example. Or data based like cache invalidation issue.
2. It could also be an upstream dependency bug that got fixed once and hopefully for all. But then you didn't fix it but someone else did.
3. It could also be that in reworking some code you also as a happy accident fixed the bug without knowing how.
If it keeps coming back however it's not fixed but could be that some changes makes it less likely to trigger the bug. This happens a lot with timing related issues.

@hjk101 My mistake for misunderstanding the prompt then

@wasabi no worries, it's a good story of a really nasty bug! It's what these weekly topics are designed for.

Even though you didn't ask for it. I hope to give you some helpful insights on how to fix it if you see it happen again or similar infrequently occurring bugs.

"Just Symfony routes shenanigans..." Now *this* is why I got out of web dev. Could never understand why an opaque and complex process, such as Symfony routes, would be thought better than straightforward and more comprehensible code that did the same thing - but faster and on less resource. Apparently, we need these frameworks because they make stuff easier to maintain? But... they... don't.

@wasabi I'm not quite sure how Symphony works but I'm pretty sure your bug might have to do with (composer) autoloading.

@spongegeoff symfony is not a framework but a component library. And as far as components go a router is one of the more useful ones.
Or do you like file based routing and inconsistent custom parameter handling in every file?

@hjk101 Yes, I like file-based routing and I've never had to think about whether the parameters are consistent or not - they are easily comprehensible and maintainable, that's for sure. My stuff is straightforward, validates perfectly, loads like a rocket, users delighted.

"Symfony isn't a framework" Really? Best tell Symfony that:

Symfony Framework
The leading PHP framework to create websites and web applications.

@hjk101 You have my respect, dude. I ran off to data analysis; anyone who can work in modern web dev productively has a bigger brain than I do. Anyway, craziest bug: I switched to using a MySQL engine that (unbeknownst to me) would, if [A] a table was empty when [B] the server was restarted, reset the autoincrement value to 1 . As I usually make recordIDs start at 10000001 and routinely test for >1000 before anything happens, all sorts of stuff stopped working. Live and learn...

@spongegeoff technically you are right of course. Even PHP qualifies as a framework. The symfony project has bundles that does allow you to group out of the box framework features. However it is first and foremost a class library. A library where a lot of full blown web Frameworks like Laravel are built on top off.
And those full blown frameworks are the target of bloat and over engineering when taking about framework hate.

I've done some simple page routing stuff myself. If that is truly the best I'm all for it. As soon as there are 3 or more routes, methods separated and mixed content types a router is likely helpful. If a router is not used you either see a lot of duplicate code. Inconsistent and hard to oversee API. Or basically own implementation of a router, which can be fine but is often less efficient. Doesn't cater to metrics and lacks input sanitisation.

@hjk101 I do duplicate code to some (small) extent, but not much. Why do you think you can't have input sanitisation and validation without a framework?

I just remember seeing how sessions had to be implemented in Zend 1 and how very much easier they are in core php. I've looked at other frameworks since, but I just hate slow web pages and there was no occasion on which a backend framework made anything easier/better. I've happily used a few front end frameworks, which have saved me time and made sites look good. Overall, I always think that if a tool or technique doesn't help, it shouldn't be used.

@spongegeoff not saying you can't but others apparently can't. I've caught too many security issues this way. I'm agreing with everything you say. Web frameworks come with some measures out of the box. That helps Devs that are not fully read in on security (especially XSS enabling crap, PDO and binding params seems to have sunk in. Rarely see SQL injection).

I'm primarily using Go now and use deps sparingly. If it's stupid simple I can just use the http package that comes with the standard library, if it's slightly more API like, you get a lot out of Chi. Perhaps that is why I'm biased towards using a router lib. For Go there is one for every level of complexity and they are really good: clear, extensible code and fast.