0

I am using the quarkus-oidc-client-filter in a Lambda calling an external service and that works brilliantly. Unfortunately, the calls to the Lambdas can be bursty. When a big burst hits after a quiet period I can get rate limited on calls to the external services token endpoint. For that reason, I was hoping to share tokens between the Lambdas and have created a token provider for that purpose, following some of the Quarkus examples. However, when the Lambda starts up I get a ContextNotActiveException on my filterRequest. My TokenProvider signature is

@Provider
@Singleton
@Unremovable
@Priority(Priorities.AUTHENTICATION)

public class OidcClientRequestFilterShared extends AbstractTokensProducer implements ClientRequestFilter 

and the accompanying errors

Caused by: javax.enterprise.context.ContextNotActiveException
    at io.quarkus.arc.impl.ClientProxies.getDelegate(ClientProxies.java:46)
    at io.quarkus.oidc.client.runtime.TokensProducer_ProducerMethod_produceTokens_494654c3bfa2346b017c24e2e2c4fcfc99087d0e_ClientProxy.arc$delegate(Unknown Source)
    at io.quarkus.oidc.client.runtime.TokensProducer_ProducerMethod_produceTokens_494654c3bfa2346b017c24e2e2c4fcfc99087d0e_ClientProxy.getAccessToken(Unknown Source)
    at com.acme.myapp.lambda.oidc.OidcClientRequestFilterShared.filter(OidcClientRequestFilterShared.java:52)
...

2022-01-27 12:35:02,037 INFO  [com.acm.mya.lam.SendMessageResource] (main) Sending message to app service
2022-01-27 12:35:04,027 WARN  [org.jbo.res.res.i18n] (main) RESTEASY002160: Provider instance com.acme.myapp.lambda.oidc.OidcClientRequestFilterShared is already registered.  2nd registration is being ignored.
javax.enterprise.context.ContextNotActiveException: javax.ws.rs.ProcessingException
javax.ws.rs.ProcessingException: javax.enterprise.context.ContextNotActiveException
    at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:780)
    at org.jboss.resteasy.microprofile.client.impl.MpClientInvocation.filterRequest(MpClientInvocation.java:75)
...

1 Answers1

0

Turns out this is a red herring. There were errors elsewhere in the code that did not get the chance to output their own error messages but instead, these were swallowed by the framework and the CDI generated errors were output. I'll put this down to a learning experience.