Stack app: `Deploy` shows success ("Deployed") but does not restart the task for a pinned external image

What problem will this feature address?

What problem will this feature address?

A Stack (Docker Swarm) application whose service uses a pinned external image (no build:) and bind-mounts its config files (e.g. ./app.conf:/etc/app/app.conf:ro) does not apply config-only changes on Deploy.

After the deploy webhook fires, the UI shows the deployment as "Deployed" (success), but the container/task is not recreated ("Up Xh" unchanged) and the new bind-mounted config is not active. Reload does nothing; only Stop → Deploy applies the change. The success status is misleading.

Root cause: docker stack deploy re-applies the stack, but when the service spec is unchanged Swarm does not restart the task. Bind-mount file changes are not part of the spec hash, so the running task keeps the old config. Forcing a restart requires docker service update --force <stack>_<service>.

Verified on v0.29.8.

Describe the solution you'd like

A force/recreate option for Stack deploys — a UI toggle plus a webhook/API param — equivalent to running docker service update --force <stack>_<service> after the docker stack deploy. This makes config-only (and other non-spec) changes take effect without a manual Stop.

Alternatively, document how to force task recreation in Stack mode via the Advanced → Command override (Compose mode already documents --force-recreate; Stack has no equivalent flag).

Describe alternatives you've considered

• Switch to Compose mode and set --force-recreate via Advanced → Command (documented, works) — but this only helps users who don't need Swarm. Users relying on Stack/replicas/multi-node have no option.
• Custom Command stack deploy -c <path> <stack> && service update --force <stack>_<svc> — hacky, requires resolving the full service name, and chains two commands.
• Manual Stop → Deploy — works but is not scriptable from CI via the deploy webhook.

Related: #2223, #750, #2318 — same family (container not replaced on redeploy), but those are build/image-digest scenarios. This is the pinned-image + bind-mount-config + Stack case, not covered by the #2318 fix.

Additional context

No response

Will you send a PR to implement it?

No

Start by tracing the Stack deploy webhook/API path and the UI controls for Stack deployments, then locate where docker stack deploy is invoked. Compare this with the Compose mode handling of --force-recreate. Done means a Stack deployment can request forced task recreation through the UI and webhook/API, with the behavior documented or covered by the relevant checks.