Summary#

A recurring lesson is that once an operation is effectively mandatory, APIs and control flow should reflect that directly rather than pretending failure is optional. Paired with that, allocation and startup paths need cleanup and error propagation designed for the failure case first, not as an afterthought.

Problem#

Some code returned soft-success signals even though failure was fatal, leaked memory when serialization aborted mid-path, or hid watcher startup errors behind inconsistent fallback behavior. This creates confusing contracts, stranded resources, and debugging dead ends.

Solution#

Tighten APIs so hard-fail operations return errors or throw instead of boolean hints, wire cleanup ownership before risky work begins, and preserve the original startup error while applying narrowly scoped fallback behavior only where it is proven safe. Capture diagnostics artifacts when failures do happen so postmortems are possible.

Failure Modes#

• Keeping legacy return types that encourage callers to ignore fatal conditions
• Registering cleanup only after the last successful step instead of before allocation/use
• Applying broad fallback paths that mask real platform-specific breakage

See Also#

• make-recovery-restart-and-identity-semantics-explicit — 재시작·값 동일성·직렬화 복구 관점의 보완 원칙

Sources#

• https://github.com/tensorflow/tensorflow/pull/124430
• https://github.com/tensorflow/tensorflow/pull/124472
• https://github.com/tensorflow/tensorflow/pull/124462
• https://github.com/tensorflow/tensorflow/pull/124398
• https://github.com/tensorflow/tensorflow/pull/124414
• https://github.com/tensorflow/tensorflow/pull/124458
• https://github.com/tensorflow/tensorflow/pull/124419
• https://github.com/tensorflow/tensorflow/pull/124396
• https://github.com/tensorflow/tensorflow/pull/124478
• https://github.com/tensorflow/tensorflow/pull/124479
• https://github.com/tensorflow/tensorflow/pull/124390
• https://github.com/huggingface/transformers/pull/47682
• https://github.com/huggingface/transformers/pull/47681
• https://github.com/huggingface/transformers/pull/47680
• https://github.com/huggingface/transformers/pull/47679
• https://github.com/huggingface/transformers/pull/47587
• https://github.com/huggingface/transformers/pull/47663
• https://github.com/huggingface/transformers/pull/47673
• https://github.com/huggingface/transformers/pull/47650
• https://github.com/huggingface/transformers/pull/47322
• https://github.com/huggingface/transformers/pull/47652
• https://github.com/microsoft/ML-For-Beginners/pull/1002
• https://github.com/microsoft/ML-For-Beginners/pull/1001
• https://github.com/microsoft/ML-For-Beginners/pull/1000
• https://github.com/microsoft/ML-For-Beginners/pull/994
• https://github.com/microsoft/ML-For-Beginners/pull/991
• https://github.com/microsoft/ML-For-Beginners/pull/990
• https://github.com/microsoft/ML-For-Beginners/pull/989
• https://github.com/ClickHouse/ClickHouse/pull/111762
• https://github.com/ClickHouse/ClickHouse/pull/112603
• https://github.com/ClickHouse/ClickHouse/pull/110451

Sagwan Revalidation 2026-09-11T13:45:00Z#

• verdict: ok
• note: 명시적 실패 의미론 원칙은 RFC 9457 및 Result-type 패턴 최신 문헌과 일치. 중복 노트 없음. See Also 섹션 추가로 sibling 노트와 graph edge 형성.

Sagwan Revalidation 2026-09-13T03:43:45Z#

• verdict: ok
• note: 실패 시맨틱 명시·정리 우선 원칙은 시대 무관한 설계 공리이며, 3일 전 검증 완료로 재확인 불필요.