Everything in this one came out of one thread with @NotRetarded over two days (#63) — three things he reported, three I found looking for them, and eleven more that a pre-release audit turned up afterwards.
Fixed
A bare /audit in Telegram answered with nothing at all. /audit <name> worked, so the command looked half-built rather than broken. It reached for an attribute TelegramBot does not have, the error went up into the poll loop, and the chat stayed silent.
/audit printed "Mount to reach it" with a hole where the path belongs — twelve times in one report, for every stack under /opt/stacks.
The Discord gateway never once resumed a session. Every reconnect went: resume, gateway invalidated the session, fresh identify, connected — five log lines for what should be two, and a new IDENTIFY every time. Discord hands out a separate URL to resume on and it arrives without the API version on it; we connected to it verbatim.
Measured after guessing wrong about it twice: dropping the gateway socket from inside the container's network namespace forces the reconnect on demand, which turned a question that took hours into one that takes ten seconds. Bare URL → invalidated. Version carried over → session resumed, three times running, in 2.9s, 0.4s and 0.4s. That line had never appeared in any log on either machine.
A gateway answering 503 was met with one connection attempt per second — fourteen in twenty seconds here on 22 September, every one logged as "reconnecting in 1s". The mark that says whether the last connection had been healthy was cleared after the handshake, so a failure inside the handshake left the mark from a connection that ended hours earlier and the backoff was forgiven every time.
An idle Telegram long poll that gets reset was logged as an error — Errno 104, as often as it happened. Quiet is right for that; silent is not, so a poll that stays dead for three minutes now says so once.
/audit offered to mount a volume over Docksentry's own data directory. The container page has refused that since #2 — Portainer keeps its stacks in a volume at /data and the legacy default put ours there too. The finding I added two days ago handed it straight back out.
"Nothing on this machine holds those paths" was said when the answer was "I could not tell". An ambiguous lookup and a daemon that would not answer both came out as that one confident line. They are separate answers now.
One vanished container blinded the whole report. docker inspect exits 1 when any single id is unknown and still prints valid JSON for the rest, and ps -aq and inspect are two calls — so anything removed in between made /audit answer "I could not tell" on a host whose daemon knew perfectly well.
Added
Docksentry names the container that actually holds a Compose file it cannot reach. "The mount is there; the source is the wrong directory" stops one word short of the answer — @NotRetarded read it three times before writing back "nothing in that section tells me where it really is." The daemon knows which container a path is inside, and both /audit and the container page read it from one place now. When nothing here holds the path, it says so; when it cannot tell, it says that instead of guessing.
What is worth testing
/auditwith no container name, in Telegram. That is the one that was silent.- Your Discord log after a reconnect — two lines now, and
session resumedwhere there used to be an invalidated session. - Whether
/auditfinally names the directory for those three QNAP stacks.