## TL;DR
The mount had already failed and the agent polled its stale in-progress view for a day: mount operations have terminal failure states the poller must read from the task's own status, not infer from the mount's absence. Fetch the operation's status directly, map its failure states to an immediate report, and add a poll budget after which the agent escalates with the last status instead of continuing to call the operation pending.

```text
agent timed out polling a Rubrik mount that had already failed and reported the restore as still in progress for a day
```

## Use this when
- The job or restore fails with this symptom: agent timed out polling a Rubrik mount that had already failed and reported the restore as still in progress for a day.
- You are working on an agent waiting on Rubrik live mount operations during restore tests and the failure repeats on the same target or schedule.
- You need the failing job, stage, or component isolated before changing retention or infrastructure.

## Not for this skill when
- A mount that is genuinely long-running on a huge dataset, where the fix is a budget matched to the operation class rather than a short one.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Retrieve the mount operation's current status and history directly and find when it actually failed. Verify: the true timeline is established
2. Identify why the poller missed it: cached response, a status field it never checks, or polling the wrong object. Verify: the blind spot is named
3. Rewrite polling to read the operation's status each cycle and exit on any terminal state, success or failure. Verify: terminal states end polling immediately
4. Add a maximum poll duration with escalation that reports the last observed status verbatim. Verify: a stuck operation escalates with evidence
5. Re-run a mount test, including a deliberately failing one, and confirm failure is reported within one cycle. Verify: both outcomes report promptly

## Variant phrasings
### agent polling rubrik mount already failed reported in progress day
The verbatim phrasing.
### agent mount poll terminal state missed failure budget fix
The terminal-state phrasing.
### rubrik live mount agent timeout stale status operation failed
The stale-status phrasing.

Compatibility: Agent polling of Rubrik live mount operations with terminal state handling

## Why it happens
Long operations fail silently in the gap between the operation's own state and whatever proxy the poller watches. A day of in-progress reports for a dead mount is worse than no report, because it actively reassures everyone watching the restore test programme.

## Edge cases / pitfalls
- Escalations should carry the operation id so a human can open the exact task, not search by time.
- Apply the same pattern to every long operation the agent polls; the blind spot is a habit, not a one-off.

## Provenance

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