## TL;DR
Rotation changes the ground under a file-following parser: the path now points to a new file, the old content lives under a rotated name (possibly compressed), and a parser keyed to byte offsets or a single filename either restarts (duplicates) or skips (gaps). Make the parser rotation-aware: track files by identity (inode or a rotation-aware follower), handle the compressed archive format if it must read back, and checkpoint progress by the last processed entry timestamp or ID rather than a raw offset alone.

```text
agent's log parser failed on rotated update logs
```

## Use this when
- Parsed results have gaps or duplicate bursts at predictable times (midnight, weekly) matching the rotation schedule.
- The parser errors with file-not-found or decompression issues on rotated names.
- During incidents, the exact minutes around rotation are missing from the agent view.

## Not for this skill when
- The log source itself stopped writing during that window (the service was down). The parser is innocent; the gap is real.
- Retention deletes logs faster than the agent reads them. That is a retention setting problem, fixed with the platform owner.

## Steps
1. Correlate the parse anomalies with the rotation configuration and timestamps on one host. Verify: the alignment between rotation and anomalies is shown from logs
2. Identify how the parser follows the file (path polling, offset checkpoint, tail library) and reproduce the failure by rotating manually during a parse. Verify: the loss or duplication is reproduced under controlled rotation
3. Replace or configure the follower to be rotation-aware (detect identity change, finish the old file from its rotated location, then open the new one). Verify: the controlled rotation now parses cleanly end to end
4. If historical reading matters, teach the reader the archive naming and compression of this platform rotation scheme. Verify: it can read back one full rotation cycle
5. Add parser health metrics: entries read per interval with alerts on zero-read or duplicate spikes. Verify: the next rotation anomaly, if any, is caught by the metric rather than by a human noticing a gap

## Variant phrasings
### log parser breaks on rotation rotated logs lost entries
The main phrasing.
### rotation aware log follower inode checkpoint parser
The implementation phrasing.
### logrotate compressed archive parser reads back agent
The archive phrasing.

Compatibility: Compatibility: logrotate on Linux, Windows event log rollover and archived evtx files, and vendor log rotation schemes; follower libraries differ by language.

## Why it happens
Rotation is a normal, scheduled betrayal of every assumption a simple parser makes: same path, same file, growing forever. The failure is time-predictable, which is its fingerprint, and it strikes hardest during the busiest logging moments because size-based rotation triggers early under load, exactly when an incident floods the logs the agent is trying to read. Rotation-aware following is a solved problem in mature log tooling; hand-rolled parsers have to adopt the same identity-and-checkpoint discipline.

## Edge cases / pitfalls
- Copytruncate rotation has an inherent small loss window; if the platform uses it, document the accepted loss or change the scheme to rename-and-create.
- Checkpoint by content (last entry ID or timestamp) survives file replacement better than byte offsets, at the cost of needing unique entry markers.
- Test rotation under load, not on an idle file; the race only shows when writes continue during the rotate.

## Provenance

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