[birme]

Part of Eyevinn/osaas-deploy-manager#2094 (follow-on A, client-ts). Decision by birme: new Valkey instances created through client-ts always have a password; the orchestrator is unchanged and existing password-less Valkeys are not touched.

What changes

• createInstance (@osaas/client-core) throws a typed PasswordRequired error before any request when serviceId === 'valkey-io-valkey' and Password is missing or blank. A supplied value or a {{secrets.x}} reference passes. Other service ids are untouched.
• New createValkeyPasswordSecret(ctx, name) (random 32 bytes, base64, stored with saveSecret('valkey-io-valkey', name, ...), returns the {{secrets.<name>}} reference) and buildRedisUrl() (URL-encodes the password).
• Generating callers:
  • osc create valkey-io-valkey <name> generates when no -o Password=... is given. Prints the secret name only.
  • osc web config-create: generates the Valkey password, stores the whole redis://:<encoded pw>@host:port URL as secret redisurl<name> under eyevinn-app-config-svc, and passes RedisUrl: '{{secrets.redisurl<name>}}' (the orchestrator only resolves a reference that is the entire value).
  • VOD pipeline (createRedis): generates the password; the URL is stored per consuming service (callback listener, packager) as redisurl<name> and passed as a reference.
  • ValkeyDb.init() (@osaas/client-db, used by osc db): generates on create and returns a URL with the password.
  • setupDatabase(ctx, 'valkey', ...): now throws Password is required for valkey when no password is given, same as the postgres branch.
• Not changed: the generated helper createValkeyIoValkeyInstance (packages/services/src/generated/valkey-io-valkey.ts) stays a pass-through. It is produced by packages/services/scripts/generate.ts for every service, so there is no per-service generate step in the template; a call without Password now fails with PasswordRequired, which is the intended fail-loud. Every in-repo caller of it supplies a password (above).

What changes for existing consumers

Breaking for direct createInstance callers (and createValkeyIoValkeyInstance callers) that create valkey-io-valkey without a Password: they now get PasswordRequired instead of a password-less instance. Pass a Password or a {{secrets.x}} reference, or call createValkeyPasswordSecret first. setupDatabase(..., 'valkey', {}) without password also throws now. CLI users get a generated password by default. Existing Valkey instances are unaffected. Please consider a minor (or major, since it is a behaviour break for library consumers) bump when releasing; this PR does not bump versions, tag or publish. Known in-repo dependents of the createInstance path (deploy-manager's Valkey creators) already pass a Password.

Behavioural note: for a pipeline or ValkeyDb whose Valkey already exists, the password is not known to the client, so the URL is built without it as before (existing password-less instances keep working; a password-protected one needs the password supplied by the user).

What a human does next

Review and merge. Release is yours (versions are independent per package, lerna conventional commits): @osaas/client-core plus the dependents @osaas/cli, client-db, client-transcode. Nothing to configure. To try it on dev: osc --env dev create valkey-io-valkey tmpvalkey should print the secret name and create the instance with a password; remove it with osc remove.

Tests

npm run lint, pretty, typecheck, build, test all pass. New tests: refusal (undefined, empty, blank), passing paths (supplied value, {{secrets.x}}, non-Valkey id), generator + URL encoding, cmdCreate, web config-create, VOD pipeline, ValkeyDb and setupDatabase.

Lessons

createInstance is the single choke point all four Valkey creation paths go through, so the guard belongs there, but a guard alone turns every caller that never set a password into a throw; each one needed its own generate step (and a secret-reference for any URL that embeds the password, since the orchestrator resolves only whole-value references). The generated helper cannot carry a per-service generate step because it is emitted from one shared template.

Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com

🤖 Generated with Claude Code