feat(idl): typed gpu_fault on core.ExecutionError and workflow.ClusterEvent

[samhita-alla]

Why

Today a GPU fault that hits a running task surfaces, at best, as a free-text Kubernetes Event message copied into the attempt's cluster_events. Failure classification and the console then have to regex the text to know that a fault happened, which device, and whether it was the workload's fault or the hardware's.

This adds the data shape: GpuFault in flyteidl2.core, carried both on the cluster event that reported it and on the error the task failed with.

What

• GpuFault { kind (XID | SXID), code, name, severity (USER | WARN | CRITICAL), gpu_uuid, optional gpu_index, pci_bus_id, node, pid, process } with field-level comments on semantics (host device index, not a pod ordinal; SXid carries only the PCI id; gpu_index optional because 0 is valid).
• It lives in flyteidl2/core/execution.proto, next to ExecutionError, because both ExecutionError and workflow.ClusterEvent have to carry it and core cannot import workflow.
• core.ExecutionError.gpu_fault = 8, set when a failure was classified as caused by or coincident with a GPU fault, so consumers do not parse message.
• workflow.ClusterEvent.gpu_fault = 3, unset for every other kind of cluster event.
• workflow.ErrorInfo.code = 3, the short failure code from the plugin's ExecutionError (OOMKilled, Interrupted, GpuFallenOffBus), empty when the producer did not set one, and workflow.ErrorInfo.gpu_fault = 4 mirroring the one on ExecutionError. The executor builds ErrorInfo and had nowhere to put the code, so it was dropped before the user saw it.
• Purely additive; existing consumers are unaffected.
• Regenerated Go, Python, TypeScript and Rust.

Source of the data

A node-level agent (any component that watches the kernel log, for example a node-problem-detector style DaemonSet) tails the node kernel log for NVRM: Xid (PCI:…): <code>, pid=… lines, attributes them to the pod(s) holding the GPU, and emits a Warning Event on the task pod with a stable message format. The executor's existing pod-event watcher forwards those Events into cluster_events. The executor side that fills these typed fields from the message is stacked on top of this PR.

Notes

• No behaviour change in any service; this PR is IDL and generated code only.
• The gen/rust diff is large because the embedded FILE_DESCRIPTOR_SET byte array is one byte per line, so any descriptor change rewrites it. The generated Rust types themselves change only where the protos did.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

• main
  • feat(idl): typed gpu_fault on core.ExecutionError and workflow.ClusterEvent 👈
    • GPU fault classification: typed failure codes from Xid events #7879
      • GPU fault classification: cover the child pods of distributed tasks #7913

[samhita-alla]

/regen

[samhita-alla]

/regen

[samhita-alla]

Rebased onto main after #7882 landed: ClusterEvent field numbers 3–6 are now taken by the Kubernetes event metadata, so gpu_fault moved to field 7. No other changes.