News and analysis
Approving a change: versions, conflicts and a persisted decision
Pulumi ESC supports concurrent requests; Durable Task examines long waits. Together they clarify the boundaries of infrastructure approval.
Two teams change the same environment: one updates a connection setting while the other prepares a feature. The base configuration changes before the owner finishes reviewing both requests. If the process retains only an “approved” message, it may be unclear which version that decision covers. October publications from Pulumi and Microsoft address different sides of this situation.
Concurrent requests need explicit version comparison
On 7 October, Pulumi introduced concurrent change requests in ESC. When the base revision changes, a draft can be updated through a three-way merge; conflicts are exposed for manual resolution. The feature applies to environments with approvals enabled on Pro and Enterprise editions.
For an owner, parallel work is only part of the benefit. A proposal reviewed yesterday may rely on a different base today. Approval should therefore preserve the identity of the proposal and reveal changes made since review. If teams touch the same setting, automatic continuation without an explicit decision can hide a meaningful conflict.
A human wait should survive process interruption
On 12 October, Microsoft discussed practical Durable Task scenarios, including human approval and environment provisioning. Durable execution helps preserve the waiting workflow, while reviewer authorization, the authoritative decision and the outcome of an external action remain application responsibilities. The article’s examples illustrate architecture rather than constitute a complete tested project.
Comparing the two suggests a conditional design conclusion: a workflow needs both an identifiable change version and a preserved decision for that version. Execution history alone does not promise exactly-once external effects. Configuration merging does not establish who is authorized to approve the change either.
Test the route from request to application
In staging, create two proposals from the same base. Apply one, then reopen the other and establish whether its reviewer can see the updated foundation. For a conflicting setting, agree who decides and whether the revised proposal requires another review.
Separately stop the executor while it waits for approval. On restart, it should recover the request, deadline and persisted decision. Test a decision committed before its notification arrives. The authoritative stored decision matters more than the timing of the message.
Make acceptance concrete: the team can establish the author, reviewed version, decision and actual result of applying the change. A new runtime is not automatically necessary if the existing workflow already provides those properties.
Our background jobs and retries guide covers a neighbouring responsibility. The archived infrastructure description lists operational requirements without confirming every component was deployed. For infrastructure maintenance, discuss which changes require approval and where the workflow currently loses its state.