Test long-running connections and handling of 4xx auth errors

[anthonyreilly]

Minimal testing has been done on long-running login sessions, where a client goes idle and the with token may have been revoked or expired. Need to test and/or simulate these events to verify how the library handles these situations.

https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/streaming_handling_errors.htm

[sergey-bulavskiy]

Hey, wanted to clarify as it is not clear. Some kind of authentication-info caching is supported? Havent found anything about it. I mean currently i register client as a scoped entity, so i'm thinking about switching to singleton, but wandering if i'm should be the one that handle 4xx or it is handled somehow on NetCoreForce side.

[anthonyreilly]

Currently, you would need to monitor for 4xx when the token or login session expires and then refresh the token. Adding an automatic token refresh is a priority for the next release, since I'm also looking at a similar situation where I may need to switch to a long-running singleton, and having the library automatically intercept the 4xx and refresh the token would be much easier to use. This would also perform better than an app that is constantly needing to create new tokens.

https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_refresh_token_flow.htm&type=5

[senj]

This is what we use with Polly

_unauthorizedPolicy = Policy
                .Handle<ForceApiException>(faex => faex.Errors?.Any(p => p.ErrorCode == "INVALID_SESSION_ID") == true)
                .RetryAsync(1, onRetry: async (exception, retryCount) =>
                {
                    _logger.LogWarning(exception, "Session expired, refreshing token");
                    await CreateNewClientAsync(salesforceConfiguration.Value);
                });

[sergey-bulavskiy]

I made the Singleton auth info storage, with underlying AuthClient, and each time Rest client is instance (scoped) it asks for auth data from singleton auth storage, if it is about to expire (more than 1.5h) - re-loggin. Not as accurate as @senj solution, will think about using Polly.