feat/one-api

Transient SM error at cold start permanently caches null — all webhook deliveries silently skipped

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:249

When GetSecretValueCommand throws (transient network blip, IAM not yet propagated after CDK deploy), the catch block logs the error and leaves key null. cachedSealingKey = null is then stored, permanently caching the failure. Every subsequent invocation short-circuits and returns null — all deliveries silently skipped for the container's lifetime with no recovery path other than a cold start. Consider caching null only on decode failures (wrong key length), not on network/SDK exceptions, so the next invocation retries.

SEALING_KEY_ID env var not set by CDK — default 'k1' is implicit load-bearing coupling

infra/cdk/src/stacks/events/events.stack.ts:158

The Lambda reads process.env['SEALING_KEY_ID'] ?? 'k1'. This env var is absent from the CDK environment block, silently defaulting to 'k1'. If CURRENT_KEY_ID in the platform ever changes without adding a matching CDK env var, the Lambda's Map would hold the correct key bytes under the wrong ID and all sealed-secret opens would fail.

console.error logs raw AWS SDK error — secret name leaks to CloudWatch on every fetch failure

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:249

AWS SDK errors from SecretsManagerClient include the SecretId in their $metadata. console.error(..., err) logs the full secret path (batu/{env}/public-api/sealing-key) to CloudWatch on any transient failure. Anyone with cloudwatch:GetLogEvents on this function's log group can discover the secret path. Prefer: err instanceof Error ? err.message : String(err), consistent with how delivery failures are logged elsewhere.

fromSecretNameV2 grantRead produces wildcard ARN — covers AWSPREVIOUS secret version

infra/cdk/src/stacks/events/events.stack.ts:139

fromSecretNameV2 constructs an ARN with a 6-char random suffix wildcard. grantRead() therefore grants GetSecretValue on all secret versions including AWSPREVIOUS. This is consistent with the codebase pattern and the threat model is sound, but the grant is wider than strictly necessary. fromSecretCompleteArn would pin to the exact ARN but requires an out-of-band lookup at synth time.

SEALING_KEY_ID not set by CDK — silent coupling between platform constant and Lambda default

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:228

Both sides hardcode 'k1' independently. Would silently fail on key ID rotation if CDK is not updated simultaneously.

Module-level cache lacks test-reset seam — inconsistent with platform sealing-key.ts precedent

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:200

The platform-side equivalent (apps/platform/src/lib/secrets/sealing-key.ts) exports __resetSealingKeyCacheForTests() to prevent cache bleed across test invocations. The Lambda handler exports no such reset seam. Low urgency now (no tests exist), but the pattern is established and should be followed when tests are added.

Stage 2a cannot distinguish which migration refused — false-positive risk if any earlier migration fails

scripts/db/rehearse-upgrade.sh:105

Stage 2a runs all pending migrations with output fully suppressed. If any migration before 0066 fails for an unrelated reason, the script reports '✓ refused, as designed' — a false positive that masks a real failure. Should grep stderr for the guard's specific string ('REFUSING to purge') to confirm 0066 specifically was the one that refused.

rehearse-upgrade.sh not wired into any CI pipeline — guard could silently disappear

scripts/db/rehearse-upgrade.sh

The script is LOCAL ONLY and no .github/workflows file references it. The guard it tests (migration 0066 refusing when endpoints exist) protects production from silent data loss, but its correctness is only verified by manual developer invocation. A rebase or edit that removes the DO $$ block would reach production undetected.

loadSealingKey has no unit tests despite critical, non-trivial logic with three failure-prone paths

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:217

Three paths have no coverage: (1) the .trim() call described as 'load-bearing' to strip trailing newlines that produce a 33-byte buffer failing key-length validation; (2) the JSON-parse vs bare-string fallback; (3) null caching on misconfigured environments. A missing key silently skips all webhook deliveries with no retry. Add vitest unit tests with mocked AWS SDK matching the pattern in eventbridge-client.test.ts.

Stage 2a error output fully suppressed — guard's verbose operator message is invisible during rehearsal

scripts/db/rehearse-upgrade.sh:105

>/dev/null 2>&1 discards both stdout and stderr. The RAISE EXCEPTION message (which instructs the operator on recovery steps) is silently eaten. Redirecting only stdout (>/dev/null) and letting stderr through would make the guard's message visible — which is the whole point of making it verbose.

Module-level cachedSealingKey prevents test isolation — future tests must use vi.resetModules()

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:200

Once set (null or a keyring), the cache persists for the lifetime of the module in the test runner. Tests exercising loadSealingKey() across different environment-variable configurations will contaminate each other unless vi.resetModules() is used between cases. Should export a reset seam like the platform sealing-key.ts does.

No integration test for webhook dispatcher covering the new Secrets Manager key-fetch path

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts:66

The handler now fetches the key at runtime via loadSealingKey. No existing test exercises handler() end-to-end. Would catch future regressions in the key-loading path before they reach production and silently drop deliveries.

SecretsManagerClient instantiated inside try block — should be module-level singleton like EventBridgeClient

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts

The client is created at most once per container (due to the cache), but its instantiation inside the try block makes the lifecycle implicit. Hoisting it to module scope alongside cachedSealingKey mirrors the EventBridgeClient pattern in this package. Note: the dynamic import must stay inside the function due to externalModules bundling.

JSON/bare-string dual parsing: no console.warn on JSON parse failure makes format mismatches invisible

packages/event-bus/src/handlers/webhook-dispatcher.lambda.ts

The JSON parse failure is silently caught and the bare-string path handles it — intentional but silent from an operator's perspective. A console.warn (not error) when JSON.parse fails would surface format mismatches (operator stored bare base64 instead of JSON) without treating them as fatal.

SEALING_KEY_ID implicit coupling — source from secret JSON or set explicitly in CDK

infra/cdk/src/stacks/events/events.stack.ts

Both the Lambda and platform independently hardcode 'k1'. Either (a) CDK should inject SEALING_KEY_ID explicitly alongside SEALING_KEY_SECRET_NAME so the env-var path is actually exercised, or (b) store the key ID inside the secret JSON ({"key":"...","keyId":"k1"}) so the ID and key rotate atomically. Without one of these, the next key rotation is a silent divergence waiting to happen.