github amayer1983/docksentry v1.18.8
v1.18.8 — Resolver sees stopped by default + @botname targeting fixed

latest release: v1.18.9
4 hours ago

Both fixes confirmed by @famewolf in #25. His 3-bot setup with most containers stopped (not absent) on duplicate hosts was the trigger.

Fixed

Partial-name resolver now sees stopped containers by default

/status jellyfin was reporting not found from hosts where jellyfin existed but was stopped — indistinguishable from hosts that didn't have it at all. /logs <stopped> was unusable for the same reason, and stopped is exactly when you want logs (to see why it died).

The v1.18.7 call to keep running-only as default for non-lifecycle commands was the wrong instinct. Flipped: _resolve_container() now defaults to include_stopped=True. Filters out _old-suffix containers (our internal rollback leftovers from failed updates) so they don't pollute the picker.

Multi-bot @botname targeting now actually targets

v1.18.5's normalize block stripped @<anything> unconditionally, so in a 3-bot group /status@dockmox-bot jellyfin made all three bots respond. Now the bot queries getMe at startup to learn its own username, and:

Command Behaviour
/check (no @) All bots respond (broadcast)
/check@own-username Strip and handle
/check@other-bot Silent ignore

Commands without @ still broadcast to all bots — the common case for /selfupdate across all hosts.

After both fixes

Scenario Before After
/status jellyfin (jellyfin running on one host, stopped on two others) 1 × "running" + 2 × "not found" 1 × "running" + 2 × "stopped" (honest)
/logs jellyfin (jellyfin stopped) "Container not found" Historical logs from before crash
/status@docknas-bot jellyfin All 3 bots respond Only docknas-bot

Docs

README "Multi-bot setup" section documents the broadcast vs. targeted-@bot behaviour with a worked example.


docker pull amayer1983/docksentry:latest
docker compose up -d

Don't miss a new docksentry release

NewReleases is sending notifications on new releases.