fix(search): validate a new provider server before the approval transaction

[waleedlatif1]

Summary

• Approving a search provider took the connected-accounts advisory lock inside its transaction and then ran the provider server's DNS/SSRF validation while still holding it. A slow resolver held the lock and a pooled connection for the full lookup
• prepareSearchMcpProvider now runs before the transaction. It skips DNS when the organization already has the server (same as before) and validates the URL up front for a new one. createManagedMcpConnector accepts the pre-validated input, so nothing resolves under the lock
• If the server is removed between preparation and the transaction, the approval returns a conflict ("try again") instead of creating it unvalidated
• Error mapping is unchanged (toSetupError dedupes it). The organization-accounts and workspace callers still validate inside their own flow
• Responds to a review thread on v0.9.4: db contention fixes, databricks genie, snowflake cortex, additional search connectors #8356

Type of Change

• Bug fix

Testing

• New integration test: a separate connection can take the accounts lock during the DNS lookup, so the lookup runs outside the lock. The test fails on the pre-fix code
• An existing provider still approves with DNS unavailable
• Type-check and the credential-group unit suites pass

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Sep 28, 2026 2:13am UTC

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[Critical risk] Moves server validation outside the approval transaction.

The PR appears safe to merge; no outstanding finding or new blocking issue was identified.

Summary

The PR moves DNS and SSRF validation for a new search-provider server ahead of the approval transaction, while retaining an in-transaction existence check.

• Existing servers do not require another DNS lookup.
• A server removed between preparation and approval produces a retryable conflict.
• The previously reported concurrent-approval failure has a post-lookup existence recheck and an integration test.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Prepare provider outside transaction] --> B{Server exists?}
  B -->|No| C[Validate URL and resolve DNS]
  B -->|Yes| D[Open approval transaction]
  C --> D
  D --> E[Take accounts lock and recheck server]
  E -->|Exists| F[Use existing server]
  E -->|Absent and validated| G[Create server]
  E -->|Absent and not validated| H[Return retryable conflict]

Loading

_{Reviews (3) · Last reviewed commit: "Merge remote-tracking branch 'origin/sta..."}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}