Error when setting session `AF.session` for `OIDURLSessionProvider.setSession` to no events corresponding to task found.: file Alamofire/RequestTaskMap.swift, line 117

[klmitchell2]

Are you filing an issue about iOS 12? No

Describe the bug When using an Alamofire AF.session with OIDURLSessionProvider.setSession() an underlying task is not created with Alamofires RequestTaskMap

To Reproduce Steps to reproduce the behavior:

1. Create project with Alamofire 5.4.0 and AppAuth 1.40 installed via cocoa pods
2. Set OIDURLSessionProvider.setSession(AF.session)
3. Call either OIDAuthorizationService.discoverConfiguration or OIDAuthState.authState(byPresenting:tokenExchangeAdditionalParameters: presenting:callback:

The RequestTaskMap is expecting to have a task populated in its task map, but results in the error:

Fatal error: RequestTaskMap consistency error: no events corresponding to task found.: file Alamofire/RequestTaskMap.swift, line 117

Expected behavior The RequestTaskMap should have a populated task map and not result in an error when using Alamofires URLSession session.

Desktop (please complete the following information):

• OS: macOS
• Browser Safari
• Version 10.15.7

Smartphone (please complete the following information):

• Device: Simulator
• OS: iOS 14.3
• Browser safari
• Version 1.4.0

Additional context This only happens when I use Alamofire v5.0.0+ regardless of which AppAuth version I use (I was on 0.92.0 when this bug was discovered).

This may not be an AppAuth issue but I believe the source of this error is happening at

      [session dataTaskWithURL:url
             completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {

In OIDAuthorizationService.m methods discoverServiceConfigurationForDiscoveryURL or performTokenRequest:.

Note: If I pass OIDURLSessionProvider.setSession(URLSession.shared) then this error does not happen.

[jshier]

As I posted in https://github.com/Alamofire/Alamofire/issues/3196, the short term solution here is to either to use a separate URLSession instance for AppAuth. This could be either allowing AppAuth to use it's own global URLSession, or creating a separate URLSession that duplicates your Alamofire configuration and providing that separate instance to AppAuth. I don't know how AppAuth works, so I don't know if it's necessary for it to use the same URLSession instance at all.

In the long term we'll have to reevaluate these assertions in Alamofire, as accidental, intentional, or swizzled changes to our URLSession seem to trigger them more than we anticipated.