Thanks @mscottford for the PR. We consider additions to the ICoreX interfaces as breaking changes because what has happened in the past when we did this is we make the change and the users for a variety reasons update a service package, for example S3, which pulls in the Core with this change. But nothing updates the STS package which is the implementation of the ICoreX interface in this case. Then applications start failing at the runtime for missing method implementations because Core is looking for your new method in STS that didn't get updated.

So our options are either put the async methods in a new ICoreAmazonSTSAsync interface and then have Core check to see if
the loaded STS client implements ICoreAmazonSTSAsync, if so use otherwise fallback to the existing sync method. Or target the PR to V4 where we can make this type of breaking change.

Ah, that makes sense. I'll take a stab at adding a new interface. Is that something that you'd like to see in a separate PR or as commits to this one?

And do you have any guidance for the best way to go about adding tests for the logic that determines when to use the async path? I didn't find any tests for the AssumeRoleAWSCredentials.GenerateNewCredentials method.

As long as you targeting V3 then adding the ICoreAmazonSTSAsync interface in this PR makes sense.

As for tests do mean how to fallback to previous sync interface if the async interface is not around? If so unfortunately our tests are only setup for testing the tip of the codebase which of course would always have the async version. We have checks in our build system that look out for when we attempt breaking changes like this. In your case we would need to do the mix version tests manually and then add the exception in our validation checker.

@normj New interface has been added and it is only called if the ICoreAmazonSTS reference also implements ICoreAmazonSTSAsync. Otherwise, it falls back to the previous behavior which is to just use ICoreAmazonSTS.

I also added a log message to indicate that the AWSSDK.Core package needs to be updated in the event that the fallback codepath is taken.

All unit and protocol tests are passing, but I'm unsure how to do any more thorough testing with my limited understanding of the project.