Conversation
…ations
Adds an internal-token-gated controller so operators/agents can debug a
customer's dynamic-integration connection end-to-end over HTTP — without a
database tunnel and without ever exposing secret credential values. This
removes the need to decrypt credentials on a local machine (the master
ENCRYPTION_KEY never leaves the API) and runs checks on the REAL runtime
instead of a local approximation.
New endpoints (base `internal/integration-debug`, InternalTokenGuard):
- GET /connections?organizationId=&providerSlug=&connectionId=
List connections with a NON-SENSITIVE credential view + latest run summary.
- GET /connections/:connectionId
One connection's detail + recent runs (logs + results).
- POST /connections/:connectionId/run { checkId? }
Run the connection's checks on the real runtime and return findings +
passing results + logs. Reuses ConnectionCheckRunnerService, which NEVER
persists — so verification can't pollute the customer's dashboard.
Security:
- Credential metadata is derived WITHOUT decrypting. Secrets are stored as
encrypted blobs and surface only as `{ present, encrypted }`; non-secret
routing fields (api_domain, scope, region, token_type, expires_at) are
plaintext and shown directly. Defense-in-depth: any plaintext field whose
NAME looks secret is masked too, so an accidentally-plaintext secret still
never leaves the API. There is intentionally NO endpoint that returns a
decrypted secret value.
- Distinct base path avoids the sibling `internal/dynamic-integrations/:id`
param route swallowing a literal `connections` segment.
Mutations (create/update/delete integrations + checks) and run history already
exist on the sibling `internal/dynamic-integrations` controller, so applying a
fix is `PATCH /:id/checks/:checkId` — no DB writes by hand.
Not included (deliberate follow-up): a "run candidate check code" endpoint to
test a fix before applying it. That is arbitrary server-side code execution, so
it needs a review of the runtime sandbox first.
Tests: internal-integration-debug.service.spec.ts (5 tests) — credential
sanitizer masks encrypted + secret-named fields and exposes only non-secret
values, expiry flagging, null-credential, and run delegation/NotFound. New
files typecheck clean (pre-existing repo typecheck errors are unrelated).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AU5798EG3PQdRuYSPJgXmy
…e a fix before applying)
Closes the last gap that kept dynamic-integration debugging on a local machine:
running a PROPOSED fix against a customer's real credentials WITHOUT first saving
it to the live, shared check.
New endpoint (internal/integration-debug, InternalTokenGuard):
- POST /connections/:connectionId/test { code, checkId? }
Runs the supplied candidate code on the REAL runtime against the connection's
real (server-side decrypted) credentials, using the integration's real
auth/baseUrl context, and returns findings + passing results + logs.
Persists nothing and never touches the saved check.
Implementation:
- ConnectionCheckRunnerService.runCandidateCheck(): wraps the candidate code via
interpretDeclarativeCheck into a one-check copy of the integration's manifest
(so auth/baseUrl/refresh behave identically to a real run), then runAllChecks.
- The shared setup (connection/provider/manifest resolution + credential decrypt
& validation + variables + OAuth refresh callback) is extracted into two private
helpers reused by runChecks and runCandidateCheck. Pure, behaviour-preserving
extraction — the existing connection-check-runner.service.spec.ts (the AWS
prod path) still passes 6/6 unchanged.
Why it's safe / why it's better than apply-then-verify:
- The runtime already executes arbitrary check code (new AsyncFunction), and an
internal-token holder can already PATCH arbitrary code into a check and run it.
This endpoint runs the same kind of code through the same executor but persists
nothing and never mutates the shared check — strictly LESS risk than the current
"PATCH the fix into live shared code, then run to see if it worked" workflow.
Tests: +2 service tests (delegation with org resolved from the connection; NotFound
when the connection is missing). 7/7 debug-service tests pass; 6/6 runner tests pass;
touched files typecheck clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AU5798EG3PQdRuYSPJgXmy
…lkit - listConnections: replace the per-connection credential + latest-run lookups (N+1) with two batched queries (credential versions by id `in`, latest run per connection via `distinct: ['connectionId']` + ordered findMany), mapped in JS. - Guard numeric query params: parseOptionalInt() drops non-numeric input at the controller so NaN never reaches the service; service clamps are also NaN-safe (Number.isFinite) for limit and runLimit. Prevents NaN flowing into Prisma `take`. - Tests updated for the batched query shape; +1 test asserting a non-numeric limit is normalized (no NaN to the DB) and the latest run is mapped per connection. 8/8 debug + 6/6 runner tests pass; touched files typecheck clean. Note on the remaining cubic P0/P1 (candidate-code execution + shared-token / no-RBAC cross-org access): these describe the internal-token model itself — the runtime already executes arbitrary check code in-process and a token holder can already PATCH code into a check and run it, so the test endpoint adds no new capability. The real mitigation is hardening that token (timingSafeEqual + the non-prod no-token fallback), tracked separately per the PR discussion. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AU5798EG3PQdRuYSPJgXmy
…bug-api feat(integration-platform): internal debug toolkit for dynamic integrations
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Contributor
|
🎉 This PR is included in version 3.89.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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
2 participants
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.
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.
Summary by cubic
Adds an internal, token‑gated debug toolkit for dynamic integrations to inspect connections, view recent runs, run checks, and safely test candidate check code without persisting changes. Secrets are never returned.
New Features
Refactors
@trycompai/integration-platform.Written for commit 2229c77. Summary will update on new commits.