generated from john/python-template
@@ -83,11 +83,13 @@ wrong has already caused a real defect in this repository, in both directions.
|
||||
| Attribute | Audience | Reaches | Rule |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `message` | User and API clients | `ErrorEnvelope.message`, UI notifications | Stays generic. Never embed exception text, provider payloads, or filesystem paths. |
|
||||
| `detail` | Internal only | Logs, and `format_error_detail` -> `ExecutionAttempt.error_detail` and `MaintenanceRun.error_detail` | Carries the root cause. Never rendered to users or serialized into an envelope. |
|
||||
| `detail` | Internal only | Logs, and `format_error_detail` -> `ExecutionAttempt.error_detail` and `MaintenanceRun.error_detail` | Carries the root cause. Never rendered to users or serialized into an envelope without a sanitizing projection. |
|
||||
|
||||
- Putting root-cause data in `message` leaks infrastructure detail to users.
|
||||
- Omitting it from `detail` silently degrades the provenance record this system exists to preserve —
|
||||
a failed attempt whose `error_detail` says nothing is an attempt that cannot be diagnosed later.
|
||||
- Any render boundary that displays persisted `error_detail` must apply the same no-local-path rule
|
||||
as `message`: sanitize machine-local absolute paths before the text becomes user-visible.
|
||||
- When you raise from a caught exception, populate **both**: a generic `message` and a `detail`
|
||||
carrying `type(exc).__name__` and the exception text, with `raise ... from exc`.
|
||||
- `detail` is optional (`None`). A read path that assumes it is populated must handle its absence.
|
||||
|
||||
Reference in New Issue
Block a user