Silent undefined from k6/experimental/secrets.get() masks missing credentials until request failure

The short answer: there is no built-in strict mode, so the standard fix is a thin wrapper that throws on undefined, called in the init context so the run aborts before any iteration starts. That converts a late, confusing 401 into an immediate, named failure.

1. Validate at VU init and abort with a clear message

Because secrets.get(name) returns undefined silently, centralize all access behind a helper:

import secrets from 'k6/experimental/secrets';

function requireSecret(name) {
  const v = secrets.get(name);
  if (v === undefined) {
    throw new Error(`Missing required secret: ${name}`);
  }
  return v;
}

// Evaluated once per VU in the init context — a throw here aborts the run.
export const API_TOKEN = requireSecret('api_token');
export const TENANT_ID = requireSecret('tenant_id');

Throwing in the init context stops the entire run immediately, which is exactly what you want for missing credentials. If you prefer an explicit abort with a custom message over an exception, do the same check in setup() and call exec.test.abort('missing secret: api_token'). Apply the identical wrapper to __ENV lookups, since --env variables fail silently the same way — one validated config module covering both sources keeps the behavior consistent.

One caveat: a bug in the validation helper itself will also abort every run, so keep it trivial and unit-test the secrets file shape in CI (e.g., a JSON schema check) rather than adding logic to the wrapper.

2. Roadmap: no confirmed strict mode

The module is explicitly experimental, and there is no confirmed public commitment that it will gain a strict mode or throw-on-missing behavior. Treat any expectation of that as unverified. The practical implication is to pin your k6 version, isolate all secret access behind your own wrapper (as above), and check the k6 release notes and GitHub repository when upgrading — if the API changes, you only fix one call site. Do not build scripts that depend on the current return-undefined semantics staying stable.

3. Verifying propagation in k6-operator deployments

In distributed runs the secrets file must exist and be identical on every runner pod; a node-local file is the usual source of the "works on one agent, undefined on another" failure. The common pattern is:

• Mount the secrets file into every runner pod from a single Kubernetes Secret (or ConfigMap for non-sensitive values) as a volume, so there is one source of truth rather than per-node files. Restrict access with RBAC.
• Add a pre-flight check: either the init-context validation above (which runs on every pod, so any pod missing the file aborts the whole run with a clear message), or a short smoke stage before the main load stages that asserts all required keys resolve.
• For debugging a live deployment, exec into individual runner pods or add a startup log line listing which keys resolved (names only, never values) to confirm the mount is present everywhere.

Verify on your version

Because the module is experimental, confirm behavior on your installed k6: call secrets.get() for a deliberately absent key and log the result; then add the wrapper, omit a key, and confirm the run aborts at startup with your message instead of failing later with 401/400. That five-minute check removes any doubt about version-specific semantics.