feat(connectors): DATEV sandbox adapter + reload REST OAuth tools (v0.3.6)#436
Merged
Merged
Conversation
Two DATEV improvements driven by a real onboarding failure: 1. Add a dedicated "DATEV Online APIs (Sandbox)" marketplace adapter, pre-configured for DATEV's sandbox (openidsandbox authorize, sandbox-api token, platform-sandbox/v2 paths) with client_secret_basic. Every DATEV app must run in sandbox until DATEV grants production approval, and the old single adapter required editing ~9 URLs/paths by hand to get there — the error-prone step that broke onboarding. The sandbox adapter is generated from the production one (scripts/generate-datev-sandbox.mjs) so the 6 tool definitions never drift; only the environment URLs differ. 2. Reload a connector's tools into the in-memory MCP registry immediately after the OAuth token is stored. The registry caches an authConfig snapshot per tool, and the existing reload lived inside the MCP auto-discovery block — which throws for non-MCP (REST/GraphQL) servers, so REST OAuth connectors never picked up their freshly-issued token and served with a stale token-less snapshot. Now the reload runs unconditionally after the token is persisted.
Two correctness fixes for OAuth2 REST connectors (surfaced with DATEV, which rotates the refresh token on every use and uses 2-year rolling refresh tokens): - refreshToken() now re-reads the freshest authConfig from the DB before refreshing, instead of trusting the in-memory registry snapshot. The snapshot is not updated after a refresh (only the DB is), so a second refresh would replay the already-rotated token and the provider would reject it. - The OAuth callback now MERGES the issued tokens into the existing authConfig (updateAuthConfigMerge) instead of replacing it, preserving static config such as authorizationUrl and scopes that later re-authorization needs.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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.
Summary
Two DATEV improvements, both driven by a real customer onboarding failure.
1. Dedicated DATEV Sandbox adapter
Adds "DATEV Online APIs (Sandbox)" to the marketplace, pre-configured for DATEV's sandbox environment:
login.datev.de/openidsandbox/authorize, tokensandbox-api.datev.de/token, API baseplatform-sandbox/v2client_secret_basic(required by DATEV)Every DATEV app must run in the sandbox until DATEV grants production approval (a 4–12 week certification). The single production adapter required editing ~9 URLs/paths by hand to reach sandbox — the exact error-prone step that left a customer with a half-prod/half-sandbox connector. The sandbox adapter is generated from the production one (
scripts/generate-datev-sandbox.mjs) so the 6 tool definitions never drift; only the environment URLs differ. The production adapter's instructions now point to the sandbox connector instead of manual editing.2. Reload REST OAuth tools after the token is stored
The in-memory MCP registry caches an
authConfigsnapshot (including the access token) per tool. The onlyreloadConnectorTools()call lived inside the MCP auto-discovery block in the OAuth callback — which throws for non-MCP (REST/GraphQL) servers, so the reload was skipped. Result: a REST connector that just completed OAuth kept serving with the stale, token-less snapshot → tool calls went out with an empty Bearer and 401'd despite a valid token in the DB. The reload now runs unconditionally right after the token is persisted.Verification
src/connectors+src/auth: 384 tests pass (new: callback reload regression test proving the reload fires even when MCP discovery throws; DATEV adapters validate + register in the catalog).client_secret_basicaccepted by DATEV's sandbox token endpoint.