Skip to main content

error_ctx

tatara_process::configmap

Function error_ctx 

Source 
pub fn error_ctx(verb: &str, ns: &str, name: &str) -> String
Expand description

Compose the diagnostic-body head every wire-verb failure against a namespaced ConfigMap wraps around the underlying kube::Error via crate::kube_error::KubeResultExt::kube_ctx_with.

Owns the fixed <verb> ConfigMap <ns>/<name> shape as ONE substrate site, routing the <ns>/<name> join through the workspace-wide crate::qualified_process_ref composer so a future normalization of the qualified-ref shape (case-fold, unicode collation, IDN) lands at ONE site and every ConfigMap-scoped diagnostic body picks it up mechanically.

Pre-lift the 3-slot format!("{verb} ConfigMap {ns}/{name}: {e}") chain recurred at TWO hand-authored sites past the ★★ PRIME-DIRECTIVE ≥ 2 duplication threshold, both inside the closed-loop-probe’s receipt-CM idempotent-upsert idiom (tatara-closed-loop-probe::main::write_receipt_cm):

  • Verb "patch" — the create-then-409-retry arm’s PATCH-verb failure wrap (.map_err(|e| anyhow!("patch ConfigMap {ns}/{cm}: {e}"))?).
  • Verb "create" — the initial CREATE-verb non-409 failure wrap (Err(anyhow!("create ConfigMap {ns}/{cm}: {e}"))).

Both sites walked the SAME shape — take a verb, the target ConfigMap’s namespace + name, and the underlying kube::Error display — and produced the SAME “{verb} ConfigMap {ns}/{name}: {kube error}” diagnostic. Post-lift each callsite reads configmap::error_ctx(<verb>, ns, cm_name) and pipes the returned context string through crate::kube_error::KubeResultExt::kube_ctx_with, which owns the ": {e}" tail; the two halves compose to the byte-identical pre-lift diagnostic.

A future normalization step — a tracing-annotated span carrying the verb + qualified-ref for post-hoc audit, a per-verb structured- error kind so operators can filter by write-verb rather than substring-match on the message body, a wire-time hedging of the verb spelling ("PATCH" vs "patch" per a fleet convention), injection of the operator’s namespace prefix for a shared-CM deployment — lands at THIS ONE substrate primitive and every downstream ConfigMap-scoped failure diagnostic across the fleet picks up the upgrade mechanically.

Sibling to with_data on the (per-ConfigMap × substrate-owned shape) axis: with_data owns the resource-body composition; this primitive owns the failure-diagnostic composition. Both bind the ConfigMap-scoped concerns at ONE substrate module so a future ConfigMap-family expansion (a with_binary_data peer for byte payloads, a not_found_ctx peer for GET-verb 404 diagnostic bodies) lands next to the existing composers.

Theory anchor: THEORY.md §VI.1 (generation over composition — the 3-slot format!(...) chain recurred at 2 hand-authored sites past the ★★ PRIME-DIRECTIVE ≥ 2 duplication trigger and is lifted onto the ONE workspace-wide substrate owner here). THEORY.md §II.1 invariant 5 (composition preserves proofs — the pin block below binds the composer at fail-before-pass-after granularity, so a regression that reordered the head slots, drifted the fixed "ConfigMap" resource-kind literal (bypassing the routing pin at [tests::error_ctx_routes_kind_slot_through_k8s_builtin_resource_configmap_owner], which binds the Kind slot to [crate::k8s_builtin_resource::K8sBuiltinResource::ConfigMap::kind] as the ONE workspace-wide owner of the K8s-built-in wire-form identity), or dropped the qualified-ref routing back to a bare format!("{ns}/{name}") surfaces at configmap::tests::error_ctx_* rather than as silent operator-facing skew across the two consumer sites).