Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    corban123
    @corban123
    I made my entire NetworkClient a singleton, however upon attempting to make a second request, I end up with No request created yet.
    Which makes little sense to me since all that would do is force the AuthenticationInterceptor to never get deallocated
    Jon Shier
    @jshier
    Yes, Request’s creation of underlying URLRequests are asynchronous, so that will be the summary while that process is underway.
    You’ll need to store the interceptor alongside your singleton to you can use the same instance for every request.
    corban123
    @corban123
    Is there a way to apply your initial credential to the AuthenticationInterceptor late?
    Also, despite it being asynchronous, it seems like the request never gets created as I never see a secondary network call being made
    Jon Shier
    @jshier
    You can just set the property.
    That sounds like the async process never completes, perhaps because an adapter never completes.
    corban123
    @corban123
    Which property are you referring to?
    And is there a good way to track down which async process never completes?
    Jon Shier
    @jshier
    You can set credential on the interceptor.
    Sure, you set breakpoints in the various Session perform methods, especially performSetupOperations.
    corban123
    @corban123
    Seems the adapt(initialRequest callback never happens
    neither the do nor catch get called
    Jon Shier
    @jshier
    You’ll want to then set breakpoints in your adapter and see what that is.
    corban123
    @corban123
    mutableState.isRefreshing is true
    Jon Shier
    @jshier
    So a refresh started, but is still waiting. Requests won’t start, if they need the same credential, until the refresh is complete.
    corban123
    @corban123
    I see the request complete via charles though
    Jon Shier
    @jshier
    THe refresh, or the request that’s waiting?
    corban123
    @corban123
    Hmm
    The initial failed request is the only call that gets made
    The retry never gets made
    Jon Shier
    @jshier
    So then what happens to the refresh that’s fired?
    corban123
    @corban123
    I wonder if this is a misunderstanding of how refresh is expected to be used
    Jon Shier
    @jshier
    It’s to refresh your Credential while making other, failed requests wait for retry.
    corban123
    @corban123
    as refresh gets fired, it sets the isRefreshing to true, my refresh function calls to the now-singleton NetworkClient to make the call to refresh the token
    which does not get called because isRefreshing is true
    Is there an expectation of a different Session for refreshing the sessionToken?
    Jon Shier
    @jshier
    Hmm, yes, that would be an issue. Adding it on a per-request basis would work around that, you just need to ensure you’re using the same instance for all requests which need the credential.
    Seems to be a case our tests missed since we aren’t using requests to refresh the token. So a separate Session or per-request interceptor may be required for now.
    corban123
    @corban123
    So you'll need both a separate session and interceptor?
    As the interceptor contains the adapt function
    Jon Shier
    @jshier
    No, one or the other.
    corban123
    @corban123
    Ahh gotcha
    Jon Shier
    @jshier
    Either avoid putting the interceptor on the refresh request, or use a separate Session for it altogether.
    corban123
    @corban123
    Hmm, Placing the same interceptor though on the default Session instead of my custom Session runs into the same issue though
    Jon Shier
    @jshier
    You wouldn’t put the interceptor on a Session dedicated to the refresh call.
    corban123
    @corban123
    Gotcha
    Jon Shier
    @jshier
    Main Session -> refresh -> Call Refresh Session -> Call completion handler when refresh completes.
    corban123
    @corban123
    Interesting, I didn't create a separate session, instead used the same session with no interceptor that time, went well
    Jon Shier
    @jshier
    Yes, that would work too.
    corban123
    @corban123
    Hmm, one last question. If I have a static AuthenticationInterceptor, is there a reason I'm getting a crasher on the lock(); defer { unlock() } when applying the credential during a refresh?
    Jon Shier
    @jshier
    You should just call the completion handler when apply a refreshed credential, not set the property directly.
    It would be great if you could summarize your various issues and finding in an issue on GitHub.
    We can discuss and come up with solutions or changes to help.
    corban123
    @corban123
    That sounds good, I wanted to make sure that I'm not misunderstanding the usage pattern here
    Which, as I'm reading what I'm writing out loud, I can see the issue, the Authenticator is attempting to refresh, and with me attempting to re-set the credential, it's causing some major timing issues
    I appreciate all your help here Jon, in the future I'll move forward with git issues instead
    Jon Shier
    @jshier
    Intended usage is to only attach the interceptor to requests which need to be authenticated, with the refresh call not having it. But I do think we should support all of those, it’s just difficult to detect refresh requests vs. others.
    corban123
    @corban123
    I noticed comments from 2018 surrounding Alamofire implementing the ability for making long living polling requests in AF5, did that ever end up making it in?
    Jon Shier
    @jshier
    @corban123 I’m not sure what you’re referring to, but no, there are no features for something like that specifically. You could implement it as a retrier but that may not be what you really want to do.