False positive warning `[Upstash QStash] client token is not set. Either pass a token or set QSTASH_TOKEN env variable.`

[alexbepple]

I store the QStash secrets not in env variables, but in AWS Param Store. Therefore, I serve the workflow like this:

const [token, currentSigningKey, nextSigningKey] =
  await fetchSecretsFromAwsParamStore([
    'QSTASH_TOKEN',
    'QSTASH_CURRENT_SIGNING_KEY',
    'QSTASH_NEXT_SIGNING_KEY',
  ])
const qstashOptions = {
  qstashClient: new Client({ token }),
  receiver: new Receiver({ currentSigningKey, nextSigningKey }),
}
return serve(workflowFunction, {
  useJSONContent: true,
  ...qstashOptions,
}).handler

(As documented at https://upstash.com/docs/workflow/basics/serve#qstashclient and at https://upstash.com/docs/workflow/basics/serve#receiver.)

While everything works, I get an irritating warning:

WARN [Upstash QStash] client token is not set. Either pass a token or set QSTASH_TOKEN env variable.

I believe that this is a false positive and should be eliminated.

[alexbepple]

I have done some research. The warning seems to come from https://github.com/upstash/qstash-js/blob/4ae6e0412d089c5233b69ba4f0024c6226388b5c/src/client/client.ts#L414.

Here a QStash Client is initialized with the token from the env, only to later be overridden by my custom qstashClient.

One quick fix for the false positive might be sth like

qstashClient: options?.qstashClient ?? new Client({
  baseUrl: environment.QSTASH_URL!,
  token: environment.QSTASH_TOKEN!,
})

An alternative might be to change the docs at https://upstash.com/docs/workflow/basics/serve#qstashclient, instructing the user to set env in options like this: env: { QSTASH_TOKEN: token }. (I have done this in my code in order to get rid of the warning for the time being.) However, this approach has the downside that other env values won’t be passed anymore, which might be a pitfall down the road.

[CahidArda]

Thanks for the report @alexbepple, we are fixing this in the next release