SavedSearchFetcher Authentication Extension Failure

[thormanrd]

I'm seeing an authentication failure for the SavedSearchFetcher in all of my SHC members logs repeating every 30 seconds, as follows:

10-28-2022 12:52:41.505 +0000 ERROR UserManagerPro [63886 SavedSearchFetcher] - Did not find any info for user=<user redacted>
10-28-2022 12:52:41.726 +0000 INFO AuthenticationProviderSAML [63886 SavedSearchFetcher] - Calling authentication extension function=getUserInfo() for user=<user redacted>
10-28-2022 12:52:42.426 +0000 ERROR AuthenticationProviderSAML [63886 SavedSearchFetcher] - Authentication extension function=getUserInfo() returned status=failed for user=<user redacted>
10-28-2022 12:52:42.426 +0000 ERROR AuthenticationProviderSAML [63886 SavedSearchFetcher] - Error message from function=getUserInfo() : Unable to get user info for username=<user redacted>. This script only officially supports querying usernames by the User Principal Name, Object ID, or Email properties. To use other user properties, use the 'azureUserFilter' argument and search the Microsoft documentation for a full list of properties: "user resource type - Microsoft Graph v1.0" / "Properties"

The <user redacted> does not exist in our SHC nor is there such a user in our SSO system that is supplying the SAML response to our authentication extension.  We have 100's of users and 100's of saved searches, alerts, and reports running and this is the only occurrence of this situation.  

So I have two questions that I cannot answer from my investigation of the logs:

1. How can I find the source of these SavedSearchFetcher calls to the authentication extension?  Before you say look in your saved searches, remember the <user redacted> does not exist on the SHC nor in our SSO IdP.  I have looked at all SHC members ~/etc/user directories for a user that matches <user redacted> but that doesn't exist either.  Bottom line, there are no saved searches for <user redacted>.  I've also searched all the savedsearches.conf files for the <user redacted> string (e.g deprecated userid setting) and there are none of those either.  I've looked at the splunkd.log file before and after these logs (INFO level logging) and there is no help which makes some sense because this is an authorization failure, so nothing more should be happening.  
2.  What other ways trigger the SavedSearchFetcher other than a REST call or a scheduled search?  I have correlated the logs for REST calls to these logs and there is nothing matching the frequency.  And as stated above I cannot fine a scheduled search that matches either.  So where else could this be coming from?

Thanks in advance for your help with this.  

[thormanrd]

P.S. the <user redacted> is not a built in user either.  It happens to be a substring of a valid SSO/SAML account.  For example, if there was a valid SSO/SAML account called john@some-domain.com, then <user redacted> would = "john".  All of our SSO/SAML accounts are email addresses as Azure SSO expects for authN/authZ.