A skip is recorded, but it is not an execution
"When did this last actually run" is the question a trigger's record exists to answer, and it has to survive any number of skips in a row.
The rule
- A trigger keeps, per trigger, the time it last ran, the number of times it has run, and a history.
- Recording an execution advances all three.
- Recording a skip appends a history entry carrying the reason for the skip and leaves the last-run time and the run count untouched.
- The history is newest-first and holds at most the ten most recent entries from either writer, so an unattended trigger cannot grow its record without bound.
- Stored state that is not in the shape expected is read as absent (no last run, a count of zero, an empty history) rather than failing the trigger.
What it means
A skip is written for diagnosis, not treated as a run. It appends to the history like an execution does, but it leaves the last-run time and the run count exactly where they were — a schedule that decides against firing must not look, afterwards, like it fired. The distinction shows up in the history entry itself: an executed entry gets the sequence number it earned; a skipped one carries none at all.
The history is bounded independently of the count. Trimming the log to its ten most recent entries does not trim what it is counting: a trigger that has run far more than ten times still reports its true total, even though only the ten most recent entries — of either kind — remain to read back.
Example
A first execution, recorded with the message ran fine, and a skip recorded
with the reason outside time window, on the same trigger:
1nullAfter thirteen executions, only the ten most recent survive in the history — but the count itself is not trimmed with it:
13