Thanks and , since the work in modat-58 has been merged this is no longer breaking testing frontend builds.

Testing with the mod-authtoken branch referenced above seems to show that the change addresses at least this use case (a user with Okapi interface permissions can enable modules for a different tenant).

https://github.com/folio-org/mod-authtoken/pull/68

It does look like the problem is looking up the user in the wrong tenant. The ansible task that is triggering this failing request is hard-coded to "x-okapi-tenant:supertenant" and hasn't been updated recently: https://github.com/folio-org/folio-ansible/blob/20c6182f9fc8e4b7a184f781b91172c4eede6f04/roles/stripes-build/handlers/main.yml#L114

I think this is a more complete look at the okapi log that corresponds with the call highlighted above. You can see the post request for /_/proxy/tenants/diku/modules w/the user agent ansible-httpget, and then a failure to find the supertenant user in the diku tenant.

I took a sample of the okapi log while the ansible play was running, and I'll attach that here (the above excerpt starts at 4739).

Its strange that there's an issue with this particular routine, but we haven't seen failures in the other builds.

, is it possible the user belongs to supertenant, but the actual request has the diku as the tenant header? That could explain why the user cannot be found.