Commit Graph
4 Commits
Author SHA1 Message Date
kevinveenbirkenbach a8f0c74fd6 fix(flowise): tolerate a provider that has not come up yet
Fediwall#1 of run 33923190220 dies in flowise's MCP registry reconcile:
"FAILED authorizing web-app-prometheus: 400 ... Failed to connect to Custom
MCP server: SSE error: request to http://prometheusmcp:8080/mcp failed,
reason: connect ECONNREFUSED", thirty retries apart. web-app-prometheus sits
in that round's preload closure, so discovery offers it, but the log carries
no web-app-prometheus task at all: the role never ran and its sidecar never
served.

Discovery cannot see that. endpoint_unreachable rejects a provider whose
declaration lacks a port or path, a static check; nothing probes whether the
provider is listening. The platform answers runtime absence with
MCP_RECONCILE_STRICT instead, and 001aeda0b1 states the rule: a rejection
"stays non-fatal in the app pass, where a provider may still be waiting", and
"becomes fatal at the reconciliation stage, where every provider has already
run". sys-svc-mcp-reconcile sets the flag true around its loop and false after;
the group_vars default is false.

flowise's registry task never consulted it, so its own early pass failed the
play on a provider that the later convergence would have reached. It now fails
only when strict, which is exactly the reconciliation stage. The retries stay,
so a provider that appears late in the same pass is still picked up, and the
password and identity tasks above keep failing hard because they address
flowise's own container rather than a foreign one.

Two client roles that never had this problem show the shape: web-app-hermes
and web-app-openclaw call the same file from their own 00_core.yml and carry
no retries/until at all. An earlier attempt in this series deleted the call
from flowise and openwebui as a duplicate of the central stage; fifteen roles
make that call, hermes and openclaw among them, so the duplication is the
convention and that change was withdrawn.
2026-09-08 19:57:12 +02:00
kevinveenbirkenbachandClaude Opus 5 ce29195b64 fix(qdrant,flowise): authenticate the vector engine and prove what Flowise can reach
Qdrant ran with no authentication at all: its environment set the HTTP port and disabled telemetry and nothing else, so every container that reached its network held full read, write and delete access to every collection, and the MCP surface's read-only promise rested entirely on the adapter's contract naming only GET routes. Qdrant 1.19 forces authentication on every request once a read-only key is set, so the engine now declares both keys, the adapter presents the read-only one, and the full key goes only to consumers that own data here. A write route is now refused by the engine rather than only by the adapter.

Three defects in the Flowise registry path. Its tool-name check compared against a contract the role always passed as empty, so it could not fail; it now compares against the provider's declared allowlist. Its managed flow pointed a customMCP node at an input that exists on no node at this tag, while the node that does take a registry id is customMcpServerTool, and the one that takes an inline config would have embedded the bearer in the flow; the flow is now an Agentflow whose Tool node calls one named tool with fixed arguments and is executed on every deploy. Its module docstring claimed only SSE providers could be registered, while the pinned MCPToolkit connects Streamable HTTP first and falls back to SSE, so the docstring contradicted the role's own declaration.

Reaching a provider inside the container network needs HTTP_SECURITY_CHECK=false, which replaces the built-in deny list rather than merging into it, so a typo there disables every protection silently while the registry keeps working. The deploy now points a throwaway entry at loopback and at the metadata address and fails unless both are refused.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-29 00:49:58 +02:00
kevinveenbirkenbachandClaude Opus 5 9967c806bd fix(roles): follow the python scripts to their new folder
Twelve callers load their scripts with the relative form
lookup('file', 'name.py'), which resolves against the role's files/
directory. dfe7a7fdd moved those scripts into files/python/ without
updating them, so the MCP provisioning and probes of baserow, checkmk,
flowise, gitlab, homeassistant, jellyfin, n8n, openwebui and pretix, plus
n8n's AI gateway task, all resolved a path that no longer exists.

This is the second time the same relocation left callers behind. After
2aec4326a fixed the php paths, the claim that no stale references remained
came from grepping the worktree, which already carried the corrected paths;
HEAD still held the old ones. The check has to run against the commit.

Verified against HEAD this time: the eleven remaining stale relative lookups
are exactly the files in this bundle, and no other loading form (copy src,
script) carries a stale path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 12:51:10 +02:00
kevinveenbirkenbachandClaude Opus 5 a423bde6cc refactor(mcp): unify client entrypoints and read provider tokens through one lookup
Every MCP role keeps its task tree under tasks/utils/ without numeric
prefixes, so a caller can reach any of them through include_role
tasks_from. utils/roles/mapping.py holds that path as the single source.

Ansible resolves a relative include against the including file's own
directory when that file was reached by path, but against tasks/ when it
was reached through tasks_from. The same file therefore loaded from its
own role and failed from a caller using tasks_from. Every nested include
now names {{ role_path }}/tasks/utils/..., which holds under both bases,
and a lint walks each tasks_from entrypoint transitively to keep it so.
The exec-gating lint learns the same form, otherwise it loses the include
chain and reports inherited IS_STACK_HOST gates as missing.

The expression resolving a provider's stored token appeared eighteen
times. plugins/lookup/mcp_credential.py replaces it, and mcp_probe_owner
disappears from eight roles: it was only ever a step towards the bearer
and no probe read it.

The Hermes and OpenClaw probes stop aborting the play while it is still
running. Roles deploy in dependency order, so a client probing during its
own role can run before a provider exists at all, and failing there
prevents that provider from ever deploying. The verdict moves to the
reconciliation pass, gated on MCP_RECONCILE_STRICT, which the reconciler
sets and group_vars declares so the readers need no default.

The sys-svc-mcp-reconcile role is added here; wiring it into a stage is a
separate change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 21:06:31 +02:00