13

Ask me about that one time a motherfucking LOG STATEMENT caused the code to not work properly, breaking both the Test and QA environments, but failed in a way that made it maddening to figure out (in conjunction with the cloud-based hosting environment and the abomination that is centralized logging, which just makes EVERYTHING more difficult).

Actually, DON'T ask me about it, because it was today, it wasted most of my day, and I'm still salty as fuck about it.

Comments
  • 5
    We had a similar situation where UAT, DEV, and INT environments were fine, but because of a different logging configuration in prod the code was throwing errors once it got there.
    So I guess what I'm saying is - at least you found it in test :)
  • 5
    @boostedanimal Hehe, yeah, I guess that really is the silver lining :) In a weird way, it really is a blessing: it most likely avoided a problem in Prod. Still a massively frustrating day, but better than a frustrating day on the next Prod release I guess.
  • 0
    Holy shit... one of my biggest fears
  • 2
    Logging with side effects! Fun!
  • 0
    So, let me ask

    You were evaluating a function/method which results in state change and somebody suddenly changed its level to INFO or higher?
  • 0
    @asgs Partly right: there definitely was a method call inside the string being logged, but no change to log level and no side-effects. Good guess though, would make a lot of sense had that been the case. But no, I'm still tossing it around in the back of my brain trying to understand exactly why it happened. I haven't been able to make sense of it yet.
Add Comment