Skip to content

test(e2e): guard the lower bound of auth_flow TTL with a configurable expiry hook #163

Description

@aspiers

Background

PR #124 added an @otp-expiry scenario to guard the 60-minute auth_flow lifetime against accidental regressions to the OTP TTL (10 min). On review (discussion), Copilot pointed out that the scenario as written doesn't actually pin down the boundary: it backdates the auth_flow row and asserts the rejected behaviour, but never proves the row remains valid in the 11–59-min window.

If someone quietly shortened AUTH_FLOW_TTL_MS to 10 min (matching the OTP TTL), the existing scenario would still pass — because the test step expires the row regardless of what the constant says, and the assertion only covers the post-expiry rejection.

Gap

We need both halves of the boundary tested:

Row age Expected Currently covered
<10 min Flow completes via the standard path yes (every passing OTP scenario)
11–59 min Flow completes — OTP can be re-sent and the resend redeems the original auth_flow no
>60 min Flow rejects via /auth/ping → flow_expired → /auth/abort yes (the new scenario from PR #124)

The middle row is the actual regression-detection signal. Without it, AUTH_FLOW_TTL_MS could silently regress to 10 min and CI wouldn't notice.

Proposed fix

  1. Extend /_internal/test/expire-auth-flow (in packages/auth-service/src/routes/test-hooks.ts) to accept an optional offset, e.g.
    { "email": "...", "secondsAgo": 1500 }
    so callers can age the row by a configurable amount rather than always pushing it to definitely-expired. Default to the existing always-expire behaviour for backwards compatibility.
  2. Update the matching unit test (packages/auth-service/src/__tests__/test-hooks.test.ts).
  3. Add an @otp-expiry scenario in features/passwordless-authentication.feature: age the row to ~30 min, click Resend (which issues a fresh OTP under the original auth_flow), submit it, assert the flow completes successfully. This proves the row is still alive mid-window.
  4. Optionally mirror the offset support on pds-core's /_internal/test/delete-par so the PAR @par-callback-error scenario could be similarly tightened (lower priority — PAR's TTL is upstream-hardcoded so regressions are less likely from our side).

Acceptance

  • New scenario uses the configurable hook with a 30-min offset and completes successfully.
  • Existing PR test(e2e): cover auth_flow TTL regression boundary #124 scenario continues to pass (regressions in either direction are now caught).
  • Reducing AUTH_FLOW_TTL_MS below 30 min in packages/auth-service/src/lib/auth-flow.ts:24 causes the new scenario to fail in CI.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions