You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Encapsulate all output-only fields into a top-level status field #1006
Currently, output-only (server-managed) and user-controlled fields are mixed together at the top level (e.g., within Actor resources).
This creates friction during update operations:
Updating user-controlled fields requires extra care to preserve existing server-managed fields.
It complicates lifecycle management in scenarios where a server-owned field needs to outlive or be decoupled from user-controlled state.
Proposal
Separate user-controlled state from server-managed state by encapsulating all output-only fields into a dedicated top-level status field.
This aligns with standard Kubernetes-style resource conventions (e.g., spec vs. status), providing:
Clear ownership boundaries between client intent and server state.
Cleaner write/update semantics without accidental overwrites of output-only metadata.
A familiar mental model for users already accustomed to declarative APIs.
Looking at the resources we have today, almost all output only fields are top level, so the change is mechanical, there are a few exemptions:
ResourceMetadata: Mixes user controlled (atespace and name) and output only (UID, version, timestamps): I think we can probably keep this as is and special case. ResourceMetadata is already special during updates as UID and version are used for optimistic locking, atespace and ate to identify the resource to update, etc.
Actor.source_snapshot: has tag which is user controlled and two output-only fields. We could just split them, making tag a top level field and moving the other two under Actor.status.source_snapshot.
Activity
thockin commentedon Aug 18, 2026
Clarify - are you proposing to use
specandstatus, or onlystatus?I am OK with
statusjuli4n commentedon Aug 18, 2026
Only
status.Add `status` fields to Substrate resources (#1025)