High-volume failed to request authContext WARN on multi-tenant tasks app — can we disable it if we don’t need token propagation?

[openStar99]

High-volume failed to request authContext WARN on multi-tenant tasks app — can we disable it if we don't need token propagation?

What's happening

Our multi-tenant tasks app (registerAsEventProcessor: true, Redis enabled) emits a continuous stream of WARN from the /eventQueue/common logger:

failed to request authContext {
  err: 'Service requires service credentials.',
  responseCode: undefined,
  responseText: undefined
}

• All entries carry tid=- (the worker's own auth-context refresh, not per-request traffic).
• Volume is very high — ~200k lines/day on one landscape — and flat across ~80 tenants, i.e. it scales with tenant count × runner ticks.
• It appears the failure is retried every runner tick per tenant (it does not seem to be cached/backed off), which is why the volume is so high.

Impact we've observed

• No user-visible errors, no ERROR cascade. Tasks still run — callers fall back to a privileged user when authContext is null.
• The only concrete impact today is log noise polluting triage.

What we suspect

• The library tries to mint a tenant token via a xsuaa-eventQueue service binding that our app does not provide, so every refresh fails.

Questions

1. What is authContext / the xsuaa-eventQueue binding actually used for? In which scenarios does a task genuinely need it (e.g. token propagation to a remote XSUAA-protected service), vs. when is it safe to run without it?

2. If our workloads don't need token propagation, can we disable the auth-context acquisition entirely (via a config flag / env var), so it neither attempts nor warns? Is there a supported way to turn it off?

3. If we can't disable it, is the missing binding the intended trigger, and should the library back off / cache the failure instead of re-warning every tick per tenant?

4. What are the side effects of either fix — i.e. if we (a) add the xsuaa-eventQueue binding, or (b) disable auth-context acquisition — what functionality could we lose or change? Specifically, does anything in the runner / periodic events / redis pub-sub path silently depend on a valid authContext?

Environment

• @cap-js-community/event-queue@1.11.1
• @sap/cds (via internal shim), Node.js 22, SAP BTP Cloud Foundry
• Multi-tenant, HANA, Redis enabled, registerAsEventProcessor: true on the tasks app only

Happy to share logs or run experiments. Thanks!

[soccermax]

• authContext: is usually especially for logging or metering as the auth context allows to log the subdomain and other tenant information. We used that for instance to build a the correct tenant URL. If the request succeeds the result is cached. The question here for me is why not set the binding correctly and cds env to avoid this error? With only 80 tenants that would result in just a few requests

• at the moment there is no support to turn this off. Buts thats a good idea, I'll think about adding that. But please be aware this will only be done in version 2 codeline

• at the moment there is no backoff for missing credentials as this in my opinion a wrong server configuration

• recommendation would be to to add the binding there are no negative side effects