Portainer Edge Agent stack deploy idempotency during network partition retries

Context

Portainer Edge Agents maintain a persistent WebSocket connection to the Portainer Server with exponential backoff retries (default 5s, configurable via EDGE_AGENT_RETRY_INTERVAL). When the Server dispatches a stack deployment and the acknowledgment is lost due to a network partition, the Server re-sends the command on reconnect.

Problem

The Edge Agent does not implement idempotency keys for stack deployments. If the first deployment attempt partially succeeded (e.g., images pulled, some containers created) before the partition, the retry will re-execute the same deployment, potentially creating duplicate resources such as named volumes with fixed names or causing container name conflicts.

Constraints

• Stack definitions may reference non-idempotent resources (named volumes, fixed container names, host port bindings).
• The Agent’s retry logic treats all failures as transient and does not distinguish permanent errors (invalid image, resource limits) from network issues.
• Server-side snapshots are periodic; a partition longer than the snapshot interval leaves the Server with stale state.

Questions

1. Is there a supported mechanism (e.g., deployment annotations, external lock, or pre-deploy hook) to make stack deployments idempotent across Agent retries without modifying the stack definition?
2. Can the Server be configured to suppress retries for specific error classes (image pull failure, resource exhaustion) while still retrying on connectivity loss?
3. What is the recommended pattern for detecting and cleaning up duplicate resources created by a retried deployment in an automated pipeline?