Code works.

Rename a variable for clarity.
Third-party lib behaves differently, breaks things.

Change the var names back.
Still broken.

Stash changes and checkout previous commit.
Everything works.

Diff with stash.
No notable changes. (some comments, ...)

Checkout branch again, pop stash.
Broken again.

... What?

(No, third party lib did not change.)

Sounds like broken cache

Add timestamp to associated data injected in various phases of the build process and read all of them to find caches.

Didn't ruby recently (like 3 years ago) allow for non utf8 characters in variable names?

What looks like a b might talk like a b but might really be a Ь

Well.
I stumped myself and two coworkers.

None of us have a clue why it stopped working. Seriously, the diff between the working and broken code is identical except for some naming. (And reverting that didn’t fix it.)

A coworker suggested another approach, and that one worked. So yay! At least I won’t have to see this again.

It still really bothers me, though.

Clarify your OS, and just more background

Usually you can't fix these errors by simple analysis.

Reminder that the tech stack at @Root is a hot glued version potpourri of everything that was available in the last 10 years (at least that's how I remember it....)

From cache corruption to long fixed bugs if one would just update and bring everything to order to race conditions is everything possible.

Unwrapping and finding causes of bugs in CI/CD when the tech stack is unmaintained is unpleasant.

I rebooted several times the CI / CD machine when build jobs had anomalies... After nuking caches when CI / CD software was shut down.

Solved the problem in most cases

in these circumstances i would usually ask a coworker to take a checkout and see if it builds for them. if it does, i start nuking my system: deleting repo , deleting ide, deleting caches , maybe rebooting system and at worse, uninstall and reinstall the OS.

usually everything starts working before the rebooting system step

The mystery wasn’t worth the effort.

The joy of dynamic languages 👐

well, i _did_ see code so badly written that i would not at all have been surprised if the _comments_ actually broke stuff.

(like - reflection trying to look at the code-doc to determine what it should do..)

@tosensei Haha. I’ve seen code that reads comments, too.

I think I actually wrote that once, though I can’t remember (or imagine) why…

@Root well, i enforce the habit of documenting every class/property/method that is somehow exposed to the user. and especially for configuration items, it's helpful to show this documentation to the user _inside the app_ - so they know _what_they are doing wrong

Oh yes, the mysteries of software development.

delete package-json.lock and run 'npm install'

@useVim Rails, no NPM here.

Also, NPM needs to get thrown out a window anyway. Multiple windows, if possible. No need to open them first, either.

Disclaimer: I may be a little tipsy.
Slàinte! 🥃

@Root you are allowed to hate things you don't like.

This is why you should not refactor without the support of automated tests

@gosubinit

Yeah. Except that testing doesn't help in case of 3rd party libraries behaving strange.

Testing seldomly helps when the problem is random clusterfuck of the universe.

:)