We've encountered a few scenarios where the runtime (100.4) doesn't try to refresh an expired token for secured resources. The most recent one we've worked around is DownloadPreplannedOfflineMap from the DownloadPreplannedOfflineMapJob. It seems that the download doesn't try to refresh an expired token if the call returns a 498 status code.
Shortened stacktrace (removed our callstack):
Can you share some code snippet on how you are handling authentication challenge or adding credentials? At what stage in your app do you get error code 498 (invalid token)? The default client handler we use checks for requests with invalid token and if a token credential is available for the request, it will refresh the token.
You can use ArcGISHttpClientHandler.HttpRequestBegin to find out which request is failing or if you have already set challenge handler Authentication.Current.ChallengeHandler = new ChallengeHandler ((info) =>{ // you can check here });
Thanks.
I am unable to get you the exact request that fails or a code snippet at this time as I am currently working on another project but I can tell you it is the very first request DownloadPreplannedOfflineMap makes once started (a /data endpoint if I recall correctly).
We have a challenge handler set but it doesn't get called at all when this happens. The request/download task simply fails with a 498 HttpRequestException.
We get the 498 after we start DownloadPreplannedOfflineMap. By the time we get to this point, other code has already run that is using security successfully. But if the download is started after the token expires (if the app was sitting open for a while) we get the 498. If we do pretty much anything else, like re-create the preplanned map area object before we download, that will successfully refresh the token. Sometimes the refresh happens transparently by the runtime, sometimes it uses our configured challenge handler (we haven't figured out what the determining factor is that chooses which to use) and the download will occur successfully if tried after.