Two modules from the same vendor, and load order decides which one breaks
One connection succeeded, the next died with a method-not-found error naming a class neither of us had ever referenced.
Two official modules from the same vendor, in the same session. The first connects. The second fails with an error about a method not being found on some internal authentication class you have never touched.
Nothing is wrong with the credential, the permissions or the configuration. Swap the order and it works.
What is actually happening
Both modules depend on the same shared authentication library, and they ship different versions of it. A process loads one version of a given assembly and keeps it. Whichever module loads first wins, permanently, for the lifetime of that session.
If the winner is the older version, the other module then calls a method that version does not have, and you get a missing-method error rather than anything resembling a version conflict.
The fix
Load the module with the newer dependency first. Newer libraries generally still satisfy the older caller, so both work. The reverse does not hold.
If you cannot control the order, or the two versions are genuinely incompatible, use separate sessions. It is inelegant and it is reliable.
A failed attempt still loaded the assembly. You cannot fix the order inside a session that has already lost the argument. Open a fresh one.
Do not let a failure report success
Our own connect helper printed a cheerful success line immediately after the call that had just thrown, because the message was not conditional on the result. That turned a clear error into a confusing one for several minutes.
If a wrapper prints a status line, it must derive that line from what happened, not from having reached the end of the function.
The general shape
Any runtime with process-wide shared dependencies has this: language runtimes, plugin hosts, dynamically linked libraries. When two components work alone but not together, and the error names something neither of them belongs to, suspect a shared dependency resolved once and reused.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.