## TL;DR
Restart the search from the first page instead of resuming with a stored token. Page tokens expire and are tied to the exact query and server state that issued them, so a token saved across calls, runs, or a server restart comes back invalid. Page through results in one session, or re-issue the search and fast-forward by ordering and offset-style filtering on run start time.

```text
MLflow search_runs failed error 'InvalidPageTokenException: invalid page token'
```

## Use this when
- The run or call fails with this symptom: InvalidPageTokenException: invalid page token from search_runs.
- You are working on an MLflow search_runs caller paging through many runs and the failure repeats on the same run or configuration.
- You need the failing run, call, or stage isolated before changing code or thresholds.

## Not for this skill when
- A token invalidated because the filter changed between pages, where the fix is keeping one filter for the whole traversal.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Identify where the token came from: a previous response in the same session, or one stored from an earlier run or process. Verify: the token's origin is known
2. Discard stored tokens and restart pagination from the first page with the final filter and ordering fixed up front. Verify: page one returns with a fresh token
3. Traverse pages in the same process without persisting tokens between separate invocations. Verify: all pages are read in one continuous traversal
4. If the job must resume later, record the last run's start time and id and rebuild the position with a filter instead of a token. Verify: the resumed search continues from the recorded position

## Variant phrasings
### mlflow invalid page token search_runs
The verbatim phrasing.
### invalidpagetokenexception mlflow pagination resume
The resume phrasing.
### mlflow search page token expired error
The expiry phrasing.

Compatibility: MLflow 2.x and 3.x search APIs and Python client pagination

## Why it happens
Page tokens are opaque cursors encoding the query, ordering, and a snapshot position, and the server validates them against the current request and its own session state. Anything that changes between pages, or time passing across processes, makes the cursor unrecognizable.

## Edge cases / pitfalls
- Sorting changes between pages invalidate tokens as surely as filter changes; fix both before paging.
- Very large result sets are better exported once than paged repeatedly across jobs.

## Provenance

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