Surfaced in the structural review of the LLM provider write tools (#415 / PR #434).
Problem
The CLI has two near-identical write-gating helpers whose "clean gate" criteria disagree:
pipefy_cli.commands.ai_provider._provider_probe_gate treats the gate as clean only when the probe is ok and carries no problem.pipefy_cli.commands.knowledge_base._probe_gate treats it as clean when the probe is ok alone.
Both access probes can legitimately return ok: true with a partial problem: when the API returns partial data alongside GraphQL errors, the service surfaces the classified error rather than discarding it, and deliberately does not flip ok (see LlmProviderService.validate_llm_provider_access and KnowledgeBaseService.validate_knowledge_base_access). The provider gate treats that partial denial as not-clean (correct — added in #415); the knowledge-base gate reads it as full access, so a KB write can proceed when it should be blocked. That is a latent partial-denial gap on the KB write path.
Proposed change
Hoist a single strict probe_gate(probe) predicate into pipefy_cli.commands._common (clean = ok and no problem) and have both the provider and knowledge-base CLI write commands use it. This removes the duplication and closes the KB gap in one move.
Acceptance
- One shared
probe_gate helper in _common; both ai_provider and knowledge_base CLI write commands call it.
- KB write-gating rejects a probe that is
ok but carries a problem (partial denial is never read as full access).
- A test covers the KB partial-denial case (probe
ok: true + problem blocks the write).
Notes
Best done after PR #434 (which introduced _provider_probe_gate) merges, so the change is a single clean diff off dev touching both CLI modules rather than a stacked branch. This changes knowledge-base CLI write-gating to be stricter, which is why it is scoped as its own reviewed follow-up rather than folded into #434.
Surfaced in the structural review of the LLM provider write tools (#415 / PR #434).
Problem
The CLI has two near-identical write-gating helpers whose "clean gate" criteria disagree:
pipefy_cli.commands.ai_provider._provider_probe_gatetreats the gate as clean only when the probe isokand carries noproblem.pipefy_cli.commands.knowledge_base._probe_gatetreats it as clean when the probe isokalone.Both access probes can legitimately return
ok: truewith a partialproblem: when the API returns partial data alongside GraphQL errors, the service surfaces the classified error rather than discarding it, and deliberately does not flipok(seeLlmProviderService.validate_llm_provider_accessandKnowledgeBaseService.validate_knowledge_base_access). The provider gate treats that partial denial as not-clean (correct — added in #415); the knowledge-base gate reads it as full access, so a KB write can proceed when it should be blocked. That is a latent partial-denial gap on the KB write path.Proposed change
Hoist a single strict
probe_gate(probe)predicate intopipefy_cli.commands._common(clean =okand noproblem) and have both the provider and knowledge-base CLI write commands use it. This removes the duplication and closes the KB gap in one move.Acceptance
probe_gatehelper in_common; bothai_providerandknowledge_baseCLI write commands call it.okbut carries aproblem(partial denial is never read as full access).ok: true+problemblocks the write).Notes
Best done after PR #434 (which introduced
_provider_probe_gate) merges, so the change is a single clean diff offdevtouching both CLI modules rather than a stacked branch. This changes knowledge-base CLI write-gating to be stricter, which is why it is scoped as its own reviewed follow-up rather than folded into #434.