Proposal: Add cascade reactivation option to UnsafeReactivateAttribute #3838

Problem

When an admin deactivates an attribute via DeactivateAttribute, all of its attribute values are also deactivated (cascading behavior). However, when the admin later reactivates the attribute via UnsafeReactivateAttribute, only the attribute itself is reactivated — the attribute values remain inactive.

This creates an asymmetry: deactivation cascades down, but reactivation does not. For attributes with many values this is a serious usability problem — an attribute with 250 values would require ~750 clicks in the web admin (or equivalent CLI calls) to fully restore.

Proposal

Add an optional reactivate_all_values boolean field to the UnsafeReactivateAttributeRequest message:

message UnsafeReactivateAttributeRequest {
  string id = 1;
  bool reactivate_all_values = 2; // When true, reactivate all attribute values along with the attribute
}

• Default: false (preserves current behavior — no breaking change)
• When true: reactivating an attribute also reactivates all of its attribute values in a single operation

This maintains backwards compatibility while giving admins a way to fully restore an attribute and its values in one call, matching the symmetry of how DeactivateAttribute cascades deactivation to values.

Impact

• Proto: Add reactivate_all_values field to UnsafeReactivateAttributeRequest
• Platform service: Implement cascade reactivation of values when the flag is set
• otdfctl: Expose the flag as a CLI option (e.g. --reactivate-all-values)
• other consumers: Can opt in to the new behavior by setting the flag

Alternatives considered

• Always cascade reactivation: Rejected because it changes existing behavior and may surprise consumers who only want to reactivate the attribute itself.
• New versioned endpoint (v2): Unnecessary since an additive optional field is not a breaking change.