dohertj2/ScadaBridge
1
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

test(bug): SmsNotificationE2ETests SID "ACtest123" fails the ^AC[0-9a-fA-F]{32}$ guard — red since 2026-07-10 #29

New Issue
Closed
opened 2026-07-23 11:52:30 -04:00 by dohertj2 · 1 comment
dohertj2 commented 2026-07-23 11:52:30 -04:00
Owner
Copy Link
Copy Source

Severity: Medium (a shipped E2E has been failing unnoticed; also silences a secret-leak assertion) · Area: Central UI Playwright tests / Notifications · Found: Phase 1 rig gating

What

tests/ZB.MOM.WW.ScadaBridge.CentralUI.PlaywrightTests/Notifications/SmsNotificationE2ETests.cs:44 uses:

private const string TestAccountSid = "ACtest123";

The test fills that SID into the SMS-config form (line ~101). The management create path validates the Account SID against ^AC[0-9a-fA-F]{32}$ (src/ZB.MOM.WW.ScadaBridge.ManagementService/ManagementActor.cs:2205). ACtest123 is AC + 6 chars, not AC + 32 hex, so the create is rejected and the test's config-card / list assertions fail.

The guard was added 2026-07-10 (40088a21); the fixture predates it (2026-06-19), so this E2E has been red since then.

Side effect

The test's Auth-Token secret-non-leak assertion is downstream of the create and is never reached — so that safety check has been silently inert too.

Fix

Change the fixture to a valid SID form, e.g. AC + 32 hex (AC00000000000000000000000000000001), and re-verify the secret-non-leak assertion runs.

Note: the unit-level RepositoryCoverageTests also use short SIDs (ACtest123, ACbyid123) but construct SmsConfiguration directly, bypassing the guard — those are fine; only the E2E goes through the validated path.

**Severity:** Medium (a shipped E2E has been failing unnoticed; also silences a secret-leak assertion) · **Area:** Central UI Playwright tests / Notifications · **Found:** Phase 1 rig gating ## What `tests/ZB.MOM.WW.ScadaBridge.CentralUI.PlaywrightTests/Notifications/SmsNotificationE2ETests.cs:44` uses: ```csharp private const string TestAccountSid = "ACtest123"; ``` The test fills that SID into the SMS-config form (line ~101). The management create path validates the Account SID against `^AC[0-9a-fA-F]{32}$` (`src/ZB.MOM.WW.ScadaBridge.ManagementService/ManagementActor.cs:2205`). `ACtest123` is `AC` + 6 chars, not `AC` + 32 hex, so the create is **rejected** and the test's config-card / list assertions fail. The guard was added 2026-07-10 (`40088a21`); the fixture predates it (2026-06-19), so this E2E has been **red since then**. ## Side effect The test's Auth-Token **secret-non-leak assertion** is downstream of the create and is never reached — so that safety check has been silently inert too. ## Fix Change the fixture to a valid SID form, e.g. `AC` + 32 hex (`AC00000000000000000000000000000001`), and re-verify the secret-non-leak assertion runs. > Note: the unit-level `RepositoryCoverageTests` also use short SIDs (`ACtest123`, `ACbyid123`) but construct `SmsConfiguration` directly, bypassing the guard — those are fine; only the E2E goes through the validated path.
dohertj2 commented 2026-07-23 14:04:36 -04:00
Author
Owner
Copy Link
Copy Source

Fixed in c72922d4 (on main @ 8524a7f7, pushed to origin). TestAccountSid is now a valid Twilio SID (AC + 32 hex: AC00000000000000000000000000000001) so the management create guard ^AC[0-9a-fA-F]{32}$ accepts it — the config-card + Auth-Token secret-non-leak assertions run again. Verified against the guard by inspection; the E2E itself runs only against a live cluster. Unit-level RepositoryCoverageTests keep their short SIDs (they construct SmsConfiguration directly, bypassing the guard).

Fixed in c72922d4 (on main @ 8524a7f7, pushed to origin). TestAccountSid is now a valid Twilio SID (AC + 32 hex: AC00000000000000000000000000000001) so the management create guard ^AC[0-9a-fA-F]{32}$ accepts it — the config-card + Auth-Token secret-non-leak assertions run again. Verified against the guard by inspection; the E2E itself runs only against a live cluster. Unit-level RepositoryCoverageTests keep their short SIDs (they construct SmsConfiguration directly, bypassing the guard).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/ScadaBridge#29
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?