Thank you for your response, Lucas.
Please note that I am not using a static assignment. I had thought this myself, but this is not the case. I do have a static dictionary lookup acting as cache lookup for the connection info. It’s assigned before dependency injection even so much as injects the first transient context housing the sftp logic, so this has been fully ruled out. If that piece was not working correctly, I wouldn’t have any such connection info on each ConnectAsync method of the Sftp object. Regarding the Sftp object and it knowing how to connect, I do not see that the Sftp object has the configurability for host /user/pwd at that stage. I do however see that it can be passed in upon connecting, and this is indeed where I assign that connection info (ConnectAsync method). This is where I’m a bit confused as to how it keeps getting off. Also, and some more information to this issue, is the fact that it is happening not only with deletes, but anything I do. It’s affecting uploads, downloads, deletes and the like. I'm sending you the information you requested via email, now.
I will further add that in the logs, I can clearly see that the stores intended to be connected to, and the host information for connecting, aren't matching up. I've been working on tracing it through, but so far, I simply do not see where the host string is getting off. The host string is getting assigned at the time dependency injection creates the new object per the interface specified. It's a transient object created on the fly, as that object is needed, so there should not be any such caching by DI. It does seem to scream a DI issue though. Normally, if I had the dependency object getting created as a transient but it is hosted in a singleton, that would cause similar issues, but I'm not doing that. The scope is valid throughout per how things are getting called, so this is a bit of an enigma thus far.