Context
PR #14411 made the Knowledge Base empty-collection guidance cloud-aware for #14410. During cross-family review, @neo-opus-grace flagged a non-blocking follow-up: the remote deployment predicate now exists in two places and will drift as cloud transport surfaces grow.
Live evidence gathered before filing at 2026-07-02T03:13:32Z:
ai/services/knowledge-base/SearchService.mjs:164-167 chooses the remote empty-collection answer with aiConfig.transport === "sse".ai/mcp/server/knowledge-base/ingestSourceFilesTool.mjs:19-29 defines isRemoteIngestTransport() with the same aiConfig.transport === "sse" predicate for the remote ingest tool visibility and fail-closed gate.- Open issue sweep found #14410 as the shipped parent but no open ticket for centralizing this predicate.
- Knowledge Base ticket sweep found older adjacent transport/stale-handle work, but no duplicate for
isRemoteIngestTransport / getEmptyCollectionAnswer predicate consolidation.
- A2A in-flight sweep showed the #14411 review follow-up message and no competing lane claim.
Problem
The current cloud/local distinction is duplicated as a literal SSE transport check. Today that is small, but the duplicated predicate is the wrong contract boundary: KB empty guidance and remote ingest exposure both depend on whether the current deployment is remote/tenant-push capable, not on each callsite owning its own interpretation of transport.
If another remote transport spelling or cloud profile is added later, one side can update while the other remains stale. That would either show local remediation guidance in a remote deployment, or expose/gate the ingest facade inconsistently.
Intended Shape
Centralize the predicate behind a single clearly named helper such as isRemoteDeployment() or an equivalent existing-owner helper. Reuse or rename the current isRemoteIngestTransport() boundary if that is the best local ownership fit; do not add a new module unless structural pre-flight validates the owner.
The helper should express the semantic contract: remote/cloud tenant-ingestion profile, currently implemented as transport === "sse". Callers should not duplicate the literal transport check.
Acceptance Criteria
SearchService.getEmptyCollectionAnswer() and the KB ingest_source_files visibility/fail-closed gate use one shared remote-deployment predicate.- The behavior from #14411 remains unchanged: local stdio deployments get local corpus guidance; remote SSE deployments get ingestion-state guidance.
- The
ingest_source_files tool remains hidden and fail-closed for local stdio clients.
- Focused unit coverage proves local stdio and remote SSE behavior for both consumers or through their existing public seams.
- JSDoc /
@summary wording makes the helper contract semantic rather than a bare transport spelling.
Out of Scope
- Changing the supported transport matrix.
- Adding tenant ingestion features.
- Reworking global AiConfig ownership.
Related
Retrieval hint: KB empty collection remote deployment predicate; getEmptyCollectionAnswer; isRemoteIngestTransport; ingest_source_files; aiConfig.transport === "sse".
Context
PR #14411 made the Knowledge Base empty-collection guidance cloud-aware for #14410. During cross-family review, @neo-opus-grace flagged a non-blocking follow-up: the remote deployment predicate now exists in two places and will drift as cloud transport surfaces grow.
Live evidence gathered before filing at 2026-07-02T03:13:32Z:
ai/services/knowledge-base/SearchService.mjs:164-167chooses the remote empty-collection answer withaiConfig.transport === "sse".ai/mcp/server/knowledge-base/ingestSourceFilesTool.mjs:19-29definesisRemoteIngestTransport()with the sameaiConfig.transport === "sse"predicate for the remote ingest tool visibility and fail-closed gate.isRemoteIngestTransport/getEmptyCollectionAnswerpredicate consolidation.Problem
The current cloud/local distinction is duplicated as a literal SSE transport check. Today that is small, but the duplicated predicate is the wrong contract boundary: KB empty guidance and remote ingest exposure both depend on whether the current deployment is remote/tenant-push capable, not on each callsite owning its own interpretation of
transport.If another remote transport spelling or cloud profile is added later, one side can update while the other remains stale. That would either show local remediation guidance in a remote deployment, or expose/gate the ingest facade inconsistently.
Intended Shape
Centralize the predicate behind a single clearly named helper such as
isRemoteDeployment()or an equivalent existing-owner helper. Reuse or rename the currentisRemoteIngestTransport()boundary if that is the best local ownership fit; do not add a new module unless structural pre-flight validates the owner.The helper should express the semantic contract: remote/cloud tenant-ingestion profile, currently implemented as
transport === "sse". Callers should not duplicate the literal transport check.Acceptance Criteria
SearchService.getEmptyCollectionAnswer()and the KBingest_source_filesvisibility/fail-closed gate use one shared remote-deployment predicate.ingest_source_filestool remains hidden and fail-closed for local stdio clients.@summarywording makes the helper contract semantic rather than a bare transport spelling.Out of Scope
Related
Retrieval hint: KB empty collection remote deployment predicate;
getEmptyCollectionAnswer;isRemoteIngestTransport;ingest_source_files;aiConfig.transport === "sse".