

DI frameworks are tricky beasts. Either they sacrifice flexibility for simplicity (I’ve seen this done in Go and in Scala, where the DI essentially generates basic instantiation and more advanced resolution is left to the app developer) or they can get really complex but do some handy things (.Net 4.x DI frameworks like Castle Windsor provided some neat lifecycle management tools but was internally very complex).
Cycle detection gets a little hairer the more complex a dependency/ class of dependencies gets. The process itself doesn’t change but the internal representation of the graph needs to be sufficiently abstract enough to illustrate a cycle for all possible resolution scenarios.
Based on the commit to fix the particular bug, it looks like the change will address a specific scenario but will probably fail to address similar issues.
All this to say “the problem isn’t too hard to think about but the solution isn’t straight-forward”, also “this is a fine short- term fix but longer-term would involve redefining the internal representation of a dependency graph”, and finally " An LLM-provided solution is at best a band-aid, in the most generous light.’

“It sounds so insignificant when you put it like that, I can hardly believe I’m in a bread line because of a manufactured poly-crisis it was a part of!”