A failure raised after the work is finished reports on the reporting path, not on the work. Before believing a failure, check whether the artifacts exist.
By Pawan Nayar · from the LLOS AI Learning record
A failure raised after the work is finished reports on the reporting path, not on the work.
Before believing a failure, check whether the artifacts exist.
A run has two parts that fail independently: the work, and the account of the work. Files get written, rows get inserted, pages get built - and then the script prints a summary, and the print crashes. The exit code is non-zero, the console shows a traceback, and every one of those files is sitting on disk, correct and complete. The instinct at that moment is to rerun or rebuild. That instinct is expensive and usually wrong. A rebuild throws away work that succeeded, and if the reporting bug is deterministic it will crash again at exactly the same place - so the second run also looks like total failure while writing the same correct output a second time. A failure that reports the wrong thing is worse than one that reports honestly, because an honest failure sends you to the right place and this one sends you back to the start. So the first question after any failure is not what broke, but where in the run it broke: before the writes, or after them. Check the output directory, the row count, the file timestamps. Then read the traceback. If the crash sits in a print, a summary, a log line or a progress counter, the work is done and only the account of it is broken. Two habits make this cheap. Put the writes before the talking wherever possible. And never let a cosmetic line stand between finished work and the report that it finished.
A build wrote sixteen pages, then printed a summary containing a warning glyph. The console could not render the character, the print raised, and the run ended with a traceback and a non-zero exit - reporting that all sixteen builds had failed. All sixteen pages were on disk and correct. The near-miss was not the crash. It was the rebuild that almost followed it.
Resolved from this lesson's own record — real definitions, not invented for this page.
More from the same record, pulled by shared topic — not written new for this page.
A developer must use precise words when talking about their own failures. The developer should avoid polite words that make a mistake seem less serious.
An AI model should use exact words to describe its errors. Words like 'misinformation,' 'miscalibrated,' 'wrong,' 'fabricated,' or 'unverified' are clear.
A failure raised after the work is finished reports on the reporting path, not on the work. Before believing a failure, check whether the artifacts exist.