Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jon Shier
    @jshier
    Depends on what’s triggering those refreshes. You’d need to provide a full example for us to see if there’s an issue. But our tests exercise the window capability, so seeing how your code differs from them might be illuminating.
    corban123
    @corban123
    The refreshes are being triggered by the Authenticator's didRequest function coming back true. I've stuck a breakpoint within AuthenticationInterceptor, and refreshAttemptsWithinWindow comes back consistently 0
    It seems by the time isRefreshExcessive is called, mutableState.refreshTimestamps has been emptied out, but I don't see a spot in which this occurs
    Jon Shier
    @jshier
    If you can get a reproducible case, we’d appreciate an issue with an attached project so we can test it and replicate. But is it possible you’re creating new Session or authenticator instances for every request?
    corban123
    @corban123
    Hmm, singleton session, but I'm getting the feeling that the AuthInterceptor is being regenerated
    Jon Shier
    @jshier
    Are you perhaps sending one to each request rather than setting it at the Session level?
    corban123
    @corban123
    Issue for my project is that I'm unable to set the credential at the Session level
    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.