fix(smoke): use regex to avoid false-positive on placeholder in key assertion #25

2026-06-17T06:02:32Z

peptiderepo commented

2026-06-17 06:02:32 +00:00

(Migrated from github.com)

What

Fixes a spurious smoke-suite failure that was blocking the production deploy gate for all six peptiderepo estates.

Why

The write-only security assertion in tests/08-pr-vision-admin.spec.ts checked:

expect(html).not.toContain('sk-or-');

The PR Vision Settings page password input renders placeholder="sk-or-…" — an ellipsis format-hint displayed when the key is admin-managed. That placeholder contains the literal string sk-or-, so the assertion tripped even though value="" (the key is not in the HTML).

Fix

Replaced the naive toContain with a regex that matches a structurally valid OpenRouter key token:

// Before (false-positive on placeholder):
expect(html).not.toContain('sk-or-');

// After (only matches a real key):
expect(html).not.toMatch(/sk-or-v1-[A-Za-z0-9]{20,}/);

A real key follows the pattern sk-or-v1-<20+ alphanumeric chars>. The placeholder sk-or-… (unicode ellipsis, no v1- segment, no token body) never matches the regex. The assertion still catches any real key accidentally rendered server-side.

The value="" assertion is unchanged and independently guards the core write-only invariant.

Risk flags

Low. Single assertion line changed. No test logic altered, no skip guards touched. Playwright --list confirmed all 38 tests parse cleanly.

Test plan

npx playwright test --list — 38 tests, no parse errors (verified locally)
Assertion now passes against the actual page HTML (placeholder present, real key absent)
A real key accidentally rendered in HTML would still match the regex and fail the test

## What Fixes a spurious smoke-suite failure that was blocking the production deploy gate for all six peptiderepo estates. ## Why The write-only security assertion in `tests/08-pr-vision-admin.spec.ts` checked: ```ts expect(html).not.toContain('sk-or-'); ``` The PR Vision Settings page password input renders `placeholder="sk-or-…"` — an ellipsis format-hint displayed when the key is admin-managed. That placeholder contains the literal string `sk-or-`, so the assertion tripped even though `value=""` (the key is not in the HTML). ## Fix Replaced the naive `toContain` with a regex that matches a structurally valid OpenRouter key token: ```ts // Before (false-positive on placeholder): expect(html).not.toContain('sk-or-'); // After (only matches a real key): expect(html).not.toMatch(/sk-or-v1-[A-Za-z0-9]{20,}/); ``` A real key follows the pattern `sk-or-v1-<20+ alphanumeric chars>`. The placeholder `sk-or-…` (unicode ellipsis, no `v1-` segment, no token body) never matches the regex. The assertion still catches any real key accidentally rendered server-side. The `value=""` assertion is unchanged and independently guards the core write-only invariant. ## Risk flags Low. Single assertion line changed. No test logic altered, no skip guards touched. Playwright `--list` confirmed all 38 tests parse cleanly. ## Test plan - `npx playwright test --list` — 38 tests, no parse errors (verified locally) - Assertion now passes against the actual page HTML (placeholder present, real key absent) - A real key accidentally rendered in HTML would still match the regex and fail the test

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: peptide-repo/peptide-e2e#25