## TL;DR
Treat the expired session as the first hypothesis when a submit fails mid-flow: detect the login page or an unauthenticated response during the run, re-authenticate once, and replay the form from saved inputs instead of re-filling from scratch. Alert-rule forms lose all entered values on a session redirect, so the script must keep its inputs outside the page.

```text
playwright failed to submit anomaly alert rule error session expired failure
```

## Use this when
- The check or run fails with this symptom: Playwright fails to submit an anomaly alert rule because the session expired.
- You are working on an agent submitting alert rules through a dashboard UI and the failure repeats on the same data or configuration.
- You need the failing rows, rule, or stage isolated before changing thresholds or code.

## Not for this skill when
- A rule that the server rejects on validation, where the page stays signed in and shows a field error instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Keep the rule definition in the script's own data, never only in page fields, so the form can be refilled after any redirect. Verify: the full rule exists outside the browser state
2. Before submitting, assert the page is still the configuration page and not a login redirect by checking a signed-in selector. Verify: a pre-submit check catches the expired session
3. On redirect, sign in again with the stored profile flow, reopen the form, refill from the saved definition, and submit once. Verify: the rule is submitted exactly once after re-login
4. Verify the rule exists by reloading the rule list and matching its name and condition. Verify: the saved rule appears in the list with the intended settings

## Variant phrasings
### playwright submit alert rule session expired
The expired-session phrasing.
### agent form submission redirected to login dashboard
The redirect phrasing.
### anomaly rule not saved session timeout automation
The unsaved-rule phrasing.

Compatibility: Playwright browser automation on data quality dashboards with expiring sessions

## Why it happens
Dashboard sessions often expire faster than automation runs, especially while a script waits on slow pages. The expiry surfaces at submit time as a redirect to login, which looks like a form failure unless the script checks where it actually is before blaming the rule data.

## Edge cases / pitfalls
- Double submission is the classic retry bug here; the reload-and-match verify step is what makes one retry safe.
- Long-lived API keys or service sessions avoid the expiry class entirely where the dashboard offers them.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oobJIItw5CJAbr6lVYZknw