Linux Managed Run Command: approximately five-minute delay between execution success and provisioning success

Question

We observe a repeatable delay on an Ubuntu Azure VM using Managed Run Command (Microsoft.Compute/virtualMachines/runCommands, API 2025-04-01, asyncExecution=false).

Two commands ultimately completed successfully with executionState=Succeeded, provisioningState=Succeeded and exitCode=0. The scripts ran for approximately 3 seconds and 2 seconds. However, the gaps between first observed execution success and first observed provisioning success were 301.544 seconds and 300.233 seconds respectively.

We poll approximately every 5 seconds plus request time. These are observation times, not exact transition times. The second run had zero read errors. Azure Activity Log independently recorded the second command's write Succeeded event about 307.795 seconds after guest execution ended (using eventTimestamp, not submissionTimestamp).

Sanitized waagent log metadata contains status/success entries associated with that command about 4 seconds after guest execution ended. This does not establish successful upload or control-plane ingestion; we have not captured an upload acknowledgment.

Observed versions: WALinuxAgent launcher 2.11.1.4, goal-state agent 2.16.0.3, RunCommandHandlerLinux 1.3.28.

A read-only check of /etc/waagent.conf found Extensions.Enabled=y and Logs.Verbose=n, with no explicit Extensions.GoalStatePeriod override. The walinuxagent service is active/running. The documented default polling period is 6 seconds; this configuration-file check does not prove the effective in-memory interval.

We searched the public handler source/release notes but found no confirmed explanation for this approximately 300-second gap. We have not changed asyncExecution, restarted/upgraded agents, or relaxed completion verification.

Questions:

1. Is this delay a known or expected behaviour for Linux Managed Run Command with synchronous execution?
2. What supported read-only diagnostics distinguish guest status upload delay from Azure control-plane provisioning-state propagation?
3. Is there a documented mitigation that preserves both execution and provisioning completion verification?

This is a sanitized summary; resource identifiers, correlation IDs, scripts, credentials and raw logs are intentionally omitted.