What are: "Trigger Filtered" and "Agent Mismatch" in rc.14?

[begunfx]

I saw both of those appear now in rc.14 and not sure what I should do with them or what they mean:

[s-b-e-n-s-o-n]

Both pills are part of the new update eligibility model rc.13 introduced — they tell you why a row that has an available update isn't auto-updating (or, in the case of Update-all, why it's being held back from the batch). Full reference here: https://getdrydock.com/docs/configuration/actions/update-eligibility

Quick read on the two you're seeing:

🟡 Trigger filtered (trigger-not-included)

A docker / docker-compose action trigger is configured with dd.action.include (or legacy dd.trigger.include) labels, and this container's labels don't list it. The trigger is intentionally only acting on containers that opt in via labels — so this row is being skipped on purpose by your own configuration.

What to do: if you want this trigger to handle this container, add the trigger's name to the container's dd.action.include label. If you don't (e.g. you have a separate trigger for it), the pill is just informational. In rc.15 it's a soft blocker — you can still click the row's Update button (the confirm modal will warn you and switch to "Update anyway"). In v1.7.0 it becomes a hard blocker (button locked) — see DEPRECATIONS.md.

🟠 Agent mismatch (agent-mismatch)

The container is on one host (e.g. an agent), but the only docker / docker-compose action trigger is configured for a different host. Drydock won't run the trigger across hosts — it would either silently no-op or hit the wrong docker socket — so the update is hard-blocked and the per-row Update button is disabled.

What to do: configure a docker/dockercompose trigger on the same agent the container runs on. Once that trigger exists, the pill clears and the Update button unlocks.

Two follow-ups planned for an upcoming UI/UX pass

1. The pill tooltips currently use the styled tooltip directive but don't all link out to the docs — we'll make every pill one click from its docs anchor (so e.g. clicking the Trigger filtered pill opens this page at the right section).
2. A per-user opt-out toggle ("Show update eligibility pills on rows") for folks who'd rather just see the row state without the explanation pills.

Both are minor and not blocking — but they're on the list so the pills become self-explaining instead of needing a discussion thread.

[begunfx]

I'm still trying to understand the value/utility of calling out that a container isn't set for an auto update. This feels like a lot of unnecessary noise in my opinion (could create user friction). I'm still not clear what an Agent mismatch means. I have containers that live on agent hosts. Does this mean "so the update is hard-blocked and the per-row Update button is disabled." I'll be unable to manually update those containers? Again, not clear on the purpose. Is there some configuration I need to change to prevent this mis-match?

What is the ultimate purpose/goal here? Are you trying to force users to automatic updates? Is it just an awareness that a container is set to be manually updated rather than automatically? If that's your goal, I would recommend something not so in your face. It feels like I have something incorrectly configured when I see those.

Thanks!

[s-b-e-n-s-o-n]

Agreed — the row pills were too loud for setups that are working as intended. Shipping in the next RC: the row pills are off by default and gated behind a single Settings → Appearance toggle ("Auto-update diagnostic pills"). When it's off, no pills on rows. When it's on, you see them everywhere as before.

The hard-blocker 🔒 Blocked button on the row is unchanged — that's functional state (the Update button is genuinely disabled because the trigger can't reach a different host) and stays visible regardless of the pill toggle. Hover it for the reason.

If you ever want the breakdown, opening the container's detail panel always shows the full diagnostic section — that's where the per-reason explanations live now, instead of being repeated on every row.

[begunfx]

Okay. Gotya. As for the Agent Mismatch, I don't see them appearing anymore for my containers with rc.15. So maybe there was a bug fix from rc.14 related to this?

[s-b-e-n-s-o-n]

Good news, and no — no code change to agent-mismatch detection between rc.14 and rc.15 (the logic is unchanged). Two likely explanations:

1. The pill is state-driven — it only appears when one of your agent-side containers actually has an available update. If they're at-latest right now, no pill, even if a trigger-host mismatch still exists in config.
2. You may have added an agent-side docker trigger in response to my earlier note — that would correctly clear it.

Either way, the pills are going off-by-default in rc.16 anyway (per the toggle above), so this stops being a daily concern. The one rc.15 change that was in this area: clicking Update on an agent-mismatched row now gets a clean rejection instead of the old "No docker trigger found" toast — server-side hard-block enforcement.

[begunfx]

Hmm. I'm looking at my containers that do have updates. I also made no changes to my agent-side docker triggers. That's why I'm confused that I don't seem them anymore.. See screenshot:

[s-b-e-n-s-o-n]

Quick update — rc.16 ships a different fix than the toggle I floated earlier. Instead of just hiding the existing pills behind a setting, the per-row eligibility pills are gone entirely in favor of carrying the state on the Update button itself:

• ☁️ Cloud-download (muted) — eligible. Tooltip: "Update."
• ☁️ Cloud-download (amber) — soft-blocked, manual update still works. Tooltip is the soft reason (e.g. Manual update only — Trigger 'X' isn't listed in this container's dd.action.include label). Click still opens the warn-and-confirm modal.
• 🔒 Lock (gray, disabled) — hard-blocked (Agent Mismatch / No Trigger / Security Blocked / Rollback). Tooltip is the blocker message; click is a no-op.

That collapses 13 reason-specific pills into 3 visual states on the row. The full diagnostic is unchanged in the container's detail panel (slide-in / full-page) — that's where to dig in when you want the structured "why."

Re: your last screenshot specifically — those rows are all trigger-not-included, the soft reason that fires when drydock did find a docker action trigger that's reachable for that container, but the container's dd.action.include label list doesn't name it. It's mutually exclusive with agent-mismatch (which fires when no trigger is reachable on the container's host at all). So the rc.14 view that showed both pills was different containers in your fleet falling into the two different branches, not the same containers reclassifying — rc.15 didn't suppress anything.

Looking ahead, v1.6.0 has a redesigned slide-in Update Status panel scheduled (plain-language status verb + actionable conditions with deep-link buttons), plus a global Update mode setting (notify / manual / auto). For users who run drydock as a notifier and apply updates with their own tooling, notify mode will silence the eligibility surfaces entirely — making this concern moot for that workflow.

Thanks for the pushback on this; the rc.16 outcome is a much better answer than my original toggle was.

[begunfx]

Please see my original screenshot for the container Prowlarr and the last one I posted. The Agent Mismatch state was visible on the first post but in rc.15 it's not there. That's the discrepency I'm referring to.