function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Rutger GernandtRutger Gernandt 

named credentials and the mystery of Retry on 401

Deal all,

I have created an integration with an external service (Google) and am using named credentials in this use-case (with a principal user). There is  strange renewal behavior however, that seems quite reproducible:
- if I try to connect after X time (let's say an hour since this is the token window with Google), the first attempt will give an 401 Unauthorized error. 
- if I retry everything works fine 
- looking at the logs, at the named credential it states: Retry on 401 is true
- however, there is no automatic retry on 401, given that a manual second try does make it work...
- this seems to suggest that SF approach to tokens is to not renewal tokens continuesly, but to get one when needed.
- not an illogical concept given the multitenant nature and that some integrations maybe seldom used. However why does this not work then? I also cannot find any documentation on the renewal process exact nature and/or this setting. 
- I am using a Google Auth. Provider over the general one btw (if that has any influence in the backend at all beside preconfig).

Context: this is especially problematic since as a workaround I am now performing a 'dummy' GET request from the service. However that means it limits my max amount of calls to 50 instead of 100. While in theory (but very seldomly) I could get over 100 anyway and I should probably resort to a batch and/or queable apex approach, however this is so rare that it is not in the 80% range of the current implementation. Under normal circumstances I can however get around 50-70 batched calls, and because of the unexpected overhead of the dummy call this is now suddenly a problem... 

There also seems no possibily to check the token renewal date against the current date fow example? But maybe it is not even saved if my theory about the implementation is correct. The only thing I can think of atm is creating an oAuth flow myself and store it in a custom setting, but that would be quite a dissapointing workaround... There is also no possibilty to place the dml outside of the context of the call it seems to me? 

Any help is appreciated! Thanks in advance! 
Jonathan JamesJonathan James
Replying here for a bump on this thread. I am experiencing a similar issue with a custom auth provider. The flow, as it appears in debug logs, is that the Named Credential is invoked, the custom refresh() flow runs and receives a new token (presumably after the token has reached its expiration), the callout is placed, and I somehow receive a 401 from the callout -- even though the service never receives an unauthorized request, according to their logs that I've checked. In my custom implementation, I handle the 401 response and allow a run-once retry. Not a good solution. I had originally done a custom settings solutions, similar to what the OP suggested, but then tried this custom auth provider, which mostly works well aside from this extremely odd behavior. I, too, would love further insight.
Henrique CabralHenrique Cabral
I've my implementation for the Auth provider working to log in the first time and retrieve the token, but the refresh isn't being called, after my token expire if I make the callout with the 401 return, I don't get inside the refresh in the Auth. 
Even worst if I do it in the Developer Console, I have got a weird java error:
System.UnexpectedException: java.lang.IllegalArgumentException: invalid start or end
Someone with a good idea. What I'm missing here.