Read each Wazuh upgrade task status before closing the change

Bottom line: Close the upgrade from the individual task evidence, not the envelope’s success label. Preserve unresolved, failed and legacy results as different follow-up cases.

Source fact: documented behavior

The Agent upgrade module – How it works guide describes upgrade-result records with an agent identifier, task identifier, status and an error message for an Error state.

Its example response carries error: 0 while individual tasks have Updating and Error statuses.

The guide says Legacy means an older upgrade does not report the task result, which must be checked manually.

What the source does not establish

This article interprets documented upgrade-result states. It does not recommend an old target release, infer an installed version from task submission or turn a missing result into evidence that the endpoint’s service checks passed.

Applicability questions

• Which agent and task identifiers belong to the change?
• What is the current individual task status?
• Is a task-specific error message available?
• What manual evidence is required for a Legacy result?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a per-agent reconciliation of task state and actual endpoint evidence before declaring the upgrade complete.

1. Build the change list from actual agent identifiers and preserve the associated task references. Keep submission evidence separate from result evidence. When reading a returned response, inspect every intended agent entry instead of accepting a top-level success value as the outcome for the entire population. Leave an absent agent entry unresolved until its identity and task relationship are established.
2. Assign a distinct follow-up to a still-updating task, a task reporting an error and a legacy result. Preserve the available task-specific error detail for diagnosis without copying secrets from unrelated logs. For the legacy branch, name the operator and approved endpoint checks that will supply the missing outcome. Do not automatically resubmit the same upgrade merely to replace an inconvenient status entry.
3. Compare the resulting active agent version and ordinary service observations with the approved target through the deployment’s supported operational workflow. Investigate a mismatch with the endpoint owner before closing the change. Keep a disconnected endpoint or an unavailable result in the outstanding population rather than silently reducing the denominator to agents that returned convenient responses.

Verification and evidence

Proposed verification: present a reviewer with sanitized task records covering an active update, an error and a legacy result, together with an envelope reporting zero error. Ask which changes can be closed and what additional evidence each other record needs. Use clearly labeled fixtures rather than claiming a batch of actual agents has been upgraded.

For a real authorized change, retain the individual task references, observed final states, error details and endpoint version checks. Reconcile every original target with an accepted or explicitly open disposition. No upgrade request, result poll or service check was performed for this article, and the documented example is not represented as a DSE deployment outcome.

Official references

• Agent upgrade module – How it works — Wazuh; official product documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.