Function log_was_truncated 

pub fn log_was_truncated(log_text: &str) -> bool

Whether log_text is the output of a writer that hit its size bound.

The question this answers is “was THIS LOG truncated”, which is not the same question as “does this text mention the marker”. The distinction is the whole point: log text contains guest-controlled bytes, so a predicate that merely searches for the marker is a predicate a guest can satisfy.

Two anchors make it discriminate, and both are properties of how the marker is produced rather than of what it says:

1. End of file. BoundedWriter::announce_truncation writes the marker at the moment the bound is crossed and every later write is discarded, so on a truncated log the marker is the final bytes. Trailing newlines are ignored; nothing else may follow.
2. A whole line. The marker is emitted preceded by its own newline, so it occupies a line by itself. A DETLOG line always carries a <timestamp> LEVEL target: prefix and therefore can never equal it. Nor can a guest forge the line break: DETLOG renders path arguments with Debug, which escapes a newline to a literal backslash-n, so guest bytes cannot start a line at all.

A genuinely truncated log still satisfies both, so this narrows the predicate to the real condition without weakening it.

The same two anchors also accept LOG_CAP_STOP_LINE: a run stopped by --max-log-bytes loses its tail just as surely, and its log ends with that line when the stop message reached the file. A capped log whose stop message was NOT written (the cap writes it without waiting and omits it when the file cannot take it at once) ends abruptly and is not recognized here; the run’s exit status 123 is then the only record of the cap.