Repository navigation
Preserve operator config across OpenAPI re-imports (#6) - #168
Merged
Merged
Conversation
Before this, importing a spec twice into the same connector created a
new row on first run and silently skipped on second run (P2002 swallow
in createToolsFromParsed). That had two consequences:
- Any customisations the operator made between imports
(responseMapping, isEnabled) were lost on the first re-import.
- Endpoints that disappeared from the upstream spec stayed registered
forever, with no visible signal that they were stale.
The fix turns createToolsFromParsed into a reconciliation step.
Schema (additive, nullable, no backfill needed):
mcp_tools.operation_id TEXT
mcp_tools.deprecated_at TIMESTAMP(3)
OpenAPI parser:
ParsedTool.operationId is populated from the source operation when
present. Survives 3.0 and 3.1 specs.
Reconciliation:
1. Snapshot existing (non-deprecated) tools for the connector.
2. For each parsed tool, look up by operationId first, then fall
back to (method, path).
3. Match → UPDATE in place. Preserves responseMapping when the spec
doesn't declare a new one; preserves the operator's manual
isEnabled toggle; clears deprecatedAt if previously set.
4. No match → CREATE.
5. Snapshot entries unmatched by any parsed tool get
deprecatedAt = now() and isEnabled = false. They stay in the DB
so ToolRoleAccess and invocation history survive; the UI shows a
'deprecated' badge.
Response shape grows: { tools, created, updated, deprecated[], skipped[] }.
'skipped' is kept (always empty under the new strategy) for back-compat
with clients that consumed the previous shape.
Frontend:
Tool list shows a yellow 'deprecated' badge with a tooltip pointing
at the date the tool fell off the upstream spec.
Tests: 26 parser specs (added one for operationId preservation), full
backend suite 631 passing. Frontend tsc clean.
keysersoft
force-pushed
the
keysersoft/reimport-preserve
branch
from
May 12, 2026 07:42
4ed1036 to
a313ece
Compare
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Importing a spec twice into the same connector created tools on the first run and silently skipped on the second (`P2002` swallow in `createToolsFromParsed`). Two consequences:
Fix
Turn `createToolsFromParsed` into a reconciliation step.
Schema (additive, nullable; no backfill needed)
```
mcp_tools.operation_id TEXT
mcp_tools.deprecated_at TIMESTAMP(3)
```
Parser
`ParsedTool.operationId` is populated from the source operation when present (works for 3.0 and 3.1).
Reconciliation
Response shape
```json
{
"message": "Imported tools: created N, updated N, deprecated N",
"tools": [...],
"created": N,
"updated": N,
"deprecated": ["tool_name_1", ...],
"skipped": [] // kept for back-compat; always empty now
}
```
Frontend
Tool list shows a yellow `deprecated` badge next to the existing `enabled`/`disabled` pill, with a tooltip showing the date the tool fell off the spec.
Test plan