Zero Change Can Be Success
Zero change can be success
A job can complete successfully and still report that it changed nothing.
That sounds obvious until a release test says otherwise. Then "no work to do"
gets misread as "the job did not run," and the test starts defending activity
instead of defending the product promise.
The rule
Separate completion from activity.
Completion answers: did the job run and finish cleanly? Activity answers: how
much did it change? Both are useful, but they are not substitutes.
The status shape
A good status surface carries both:
- a completion marker, such as
last_success_at - an in-flight marker, such as
sync_in_progress - an activity count, such as
last_synced_count - an error field, such as
last_error
Tests should assert the field that matches the promise. If the promise is "sync
completed," assert last_success_at and sync_in_progress: false. If the
promise is "this fixture populated search," assert search results somewhere
else.
Mxr example
During the Mxr v0.5.60 release, the release smoke expected
last_synced_count > 0 after running mxr sync. The daemon had actually done
the right thing: it completed sync, set last_success_at, cleared
sync_in_progress, and reported last_synced_count: 0 because the provider had
no changes.
The fix in v0.5.61 was not to make sync pretend it changed messages. The test
now accepts a completed zero-change sync, and search is checked through the
actual search path.
Where this generalizes
Backups, queue drains, cron jobs, cache refreshes, deploy previews, migrations,
and sync loops all have this shape. A quiet run can be the best possible
outcome. Make the status say "quiet and successful" instead of forcing callers
to infer success from a nonzero count.
Evidence-backed monitoring systems adds a publication case. A monitor may publish a fresh current-state page after a clean run even when the decision state and action remain unchanged. Publication proves the run completed; it does not manufacture movement.
The same distinction appears at smaller boundaries. A command can succeed without changing anything; a step can succeed without returning data. See Empty output is still a successful result.