Lisias
commented
1 year ago HA!!! I WAS INNOCENT AFTER ALL!!! :) (or, at very least, not entirely guilty!!!)
Fellow Kerbonaut kurgut was bitten by this bug too!!!
So there's still one cache validation bug left on the code for sure!!!! :)
His last change was Rational Resources (what's probably only the trigger, as I didn't used it when I got screwed) and some custom made patches (and these ones, I had on the my affected rig!).
By inspecting these new material I hope to find some common ground that will lead me to the cause of the problem!!!
More detailed info: Logs for Lisias.zip
On https://github.com/net-lisias-ksp/KSP-Recall/issues/65 I had my arse bitten by MM (Forum), that I was still using on my Acceptance tests (the ones I do before shipping things).
Evidences pinpoints the code that checks the
ConfigCacheintegrity.MM (Forum) is terribly prone to false negatives because it doesn't recon that DIGEST IS NOT the same as IDENTITY, so on my fork I added a new criteria to help on reducing the false negatives.
So, when I updated Recall to 0.4.0.0, I'm betting I had caused (by absolute lack of luck) a digest collision - and so the Config Cache wasn't invalidated and I tested a bad code using an old Cache from the time the code wasn't bad, and didn't noticed anything wrong due some failsafes that Recall have. I should probably issue a warning on the KSP.log when a Recall failsafe is triggered.
Anyway. I had a digest collision on the GameData, but MM (forum) still adds an additional digest for the symbols created by code (see
ModuleManagerSupport.cson my add'ons), and I think that digest should had detect the change even on the MM (Forum).Since this specific piece of code is still similar on this Fork, it's reasonable to assume that this potential weakness is also affecting this fork.
This issue is to remind me to look on this matter and enhance the Cache integrity code so we can close yet another door for a potential problem.