Some library failures lack a machine-readable category #3

Activity

1. cblanquera commented on Oct 26, 2026

   

   cblanquera

   on Oct 26, 2026

   MemberAuthor

   More actions

   Suggested investigation and fix notes

   Deferred until trial/3 is merged into main. Recheck the merged source and tests first. The snippets are examples/proposals, not an approved patch or a change to frozen contracts.

   1. Inventory TransformError::new, IO/parser conversions, callback wrappers, writer locking, recovery, ownership, and selection failures. Create a small classification table before editing.
   2. Prefer an additive kind() API while keeping TransformError opaque. Audit all internal struct literals when adding a field. Retain new(message) with a deliberate fallback category for existing callers.
   3. Assign categories at failure construction; never infer them from display text. Decide whether an outer callback/install wrapper reports its phase category while retaining the underlying typed failure in source().
   4. Preserve parser spans, underlying IO errors, Send/Sync properties, public Display redaction, and error precedence. Document any public API decision before changing exported shapes.
   5. Coordinate with Discarding the original error while constructing another error #10 and Duplicating an underlying error in both the wrapper message and its source #11: retaining causes, classifying failures, and formatting the chain are separate concerns.

   A future caller should be able to do this after the proposed category API exists:

   match error.kind() {
       TransformErrorKind::LockExists => {
           // Report contention; do not automatically remove the writer lock.
       }
       TransformErrorKind::RecoveryRequired => {
           // Direct the operator to the documented explicit recovery procedure.
       }
       _ => return Err(error),
   }

   Keep tests for diagnostic wording when wording itself matters, but make recovery/classification assertions use kinds. Start with cargo test -p stackpress-idea-transformer -p stackpress-idea --locked.

   Implementation workflow: After the merge, follow .agents/workflows/rust-programming.md: prove the affected behavior, complete the three test-verified review rounds, and record relevant formatting/lints/docs, feature/platform scope, and applicable development coverage. Preserve unrelated changes.
2. cblanquera commented on Oct 26, 2026

   

   cblanquera

   on Oct 26, 2026

   MemberAuthor

   More actions

   Fixed on trial/3 in 407b4d6 + df443b7 (merged as ff7a251, task 00010 lane 2; not yet on main, so leaving open).

   • Added an additive #[non_exhaustive] TransformErrorKind with categories for lock contention, recovery required, budget/limit, ownership, selection, parse, IO and callback failures.
   • Tests show callers can tell these apart without reading message text; original IO/parser/callback causes are preserved.

   Coordinator-verified on the combined code: fmt, Clippy -D warnings, Rustdoc -D warnings, cargo +1.96.0 check, 466 workspace tests and 857 doctests pass (467 tests on merged trial/3). Coverage: server 91.61%, CLI 93.15%, transformer 93.62%.
3. cblanquera

   added a commit that references this issue on Oct 26, 2026

   Fix owner review issues #10, #3, #8, #9, #13, #12 and host parts of #4,

   ...

   407b4d6
4. cblanquera

   added

   human review

   on Oct 27, 2026