A missing dollar sign made a redeploy hook stop a container that never existed

Bash's xtrace prints each command after substitution. One traced push tells you something a fifth reading of the script cannot ^[5]. Several explanations fit the symptom, and each prints differently. A line referencing a variable that the hook's environment never set would have printed `docker stop` with an empty argument; a value containing a space, expanded unquoted, would have printed two arguments ^[2]. The push printed `+ docker stop APP_NAME` ^[6]. So the line passed the literal word `APP_NAME`, with no dollar sign in it and nothing to expand ^[3].

The post attributes the failure to inconsistent quoting, saying `$APP_NAME` had lost proper double-quote expansion on those two lines while the rest of the script used it correctly ^[8]. The trace it publishes shows something narrower. In the fix, each of the two lines gains three characters, a dollar sign and a pair of double quotes, six across the patch ^[9][1]. Only the dollar sign changed what the commands targeted: the value was `myapp`, the same single word `docker run` passed to `--name` two lines later in the same trace, and a word with no whitespace does not split when expanded unquoted ^[6][4].

The conflict was the part that showed up in the output. Every second push printed `Conflict. The container name "/myapp" is already in use` ^[2]. The two commands ahead of it were the ones at fault. They ran against a name that had never been created, and the script continued to `docker run` ^[7]. With the old container still present and the new one never created, each failed push left the previous build in place ^[5].

The manual test is what made the search expensive. `docker stop myapp` and `docker rm myapp` typed at the shell worked instantly, no errors and no delay ^[4]. That result cleared Docker. What it tested was Docker, not the hook's invocation. About two hours went into the wrong layer, on the assumption that the problem had to be Docker, WSL or something else environmental ^[10].

"Reading code shows you what you intended. Tracing execution shows you what actually happened," the author wrote ^[11]. The stated conclusion is that `set -x` now comes first, as the opening diagnostic step instead of a last resort after manual testing is exhausted ^[12]. The same account reports a second stumble on the way: pushing to `master` while following a workflow that assumed `main` was the default branch ^[13].