A generated Application change disappears or a child is removed

Understand the likely causes

• The ApplicationSet generator and template remain the authoritative source for owned child fields under effective modification policy. Editing the child does not necessarily change that durable input.
• Input selection, missing parameters, duplicate generated identities, empty output, parent policy, owner references, and Application finalizers can affect child and resource lifecycles. Automated pruning inside a child is a separate mechanism from parent-driven Application removal.

Map the full ownership chain

Record ApplicationSet identity, generator type and resolved input, template revision or configuration, expected child name and namespace, actual child identity, and relevant retained conditions. Include the project and destination selected by the generated spec. Use existing authorized metadata and redact secrets. A label saying generated is not a complete explanation; identify which definition owns the specific field and which controller observed the change.

Compare effective output with the child edit

For a reverting field, compare the generator parameters and template with the child’s intended change. Review documented modification and ignore behavior for the actual version. Go-template missing-key errors, type limitations, and parameter selection can produce a different output than a casual reading suggests. Do not broaden project or target authority to compensate for a wrong template value. The ownership map below is conceptual and performs no reconciliation.

generator input + template + parent policy -> child Application
child Application + project + target authority -> managed resources
child removal + owner/finalizer rules -> separate lifecycle decision

Separate removal from ordinary drift

If a child vanished, determine whether the input set intentionally changed, became empty, collided, or failed generation. Review parent modification policy and deletion behavior, then inspect Application owner references and resource finalizer semantics through the owner’s approved evidence path. Do not remove finalizers or recreate children blindly. Those actions can bypass intended protection, orphan resources, or trigger a different reconciliation path without resolving the source error.

Change the authoritative input through review

For a legitimate lasting change, update the appropriate parent input or template, or use the documented supported exception under a bounded policy. For accidental selection loss, restore the reviewed generator contract and assess existing child and resource state before any separately authorized recovery. Bind decisions to actual generated identities and targets. If data-bearing resources were affected, involve their owner and compatibility plan rather than assuming recreation restores authoritative state or reverses external actions.

Keep it from recurring

• Protect generator and template writers, validate generated identities and high-authority fields, keep modification and deletion policies explicit, and rehearse retirement separately from ordinary updates. Document temporary exceptions and their expiry. Review child automation changes at the parent ownership layer before relying on manual edits.