feat: add atlas-connection-error-debugger tool behind feature flag COMPASS-10835#8233
feat: add atlas-connection-error-debugger tool behind feature flag COMPASS-10835#8233paula-stacho wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a new, feature-flagged tool intended to help debug Atlas connection failures, and threads the necessary preferences/service dependencies through the generative AI and assistant surfaces so the tool can be conditionally advertised and executed.
Changes:
- Adds a new development-stage feature flag:
enableAtlasConnectionErrorDebugger. - Switches tool listing to a preference-driven
getAvailableTools(...)helper and updates assistant UI/prompting to use it. - Adds an
atlas-connection-error-debuggertool to the ToolsController (and adds a placeholderAtlasService.debugConnection()).
Reviewed changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/compass-preferences-model/src/feature-flags.ts | Adds the new feature flag definition. |
| packages/compass-generative-ai/src/tools-controller.ts | Wires preferences/atlas service into ToolsController and conditionally registers the new tool. |
| packages/compass-generative-ai/src/tools-controller.spec.ts | Updates controller construction to provide preferences/atlas service. |
| packages/compass-generative-ai/src/provider.tsx | Injects preferences + atlas service into ToolsController provider and updates exports. |
| packages/compass-generative-ai/src/index.ts | Re-exports getAvailableTools instead of AVAILABLE_TOOLS. |
| packages/compass-generative-ai/src/available-tools.ts | Introduces getAvailableTools(...) with conditional atlas debugger listing. |
| packages/compass-assistant/test/tool-calls.eval.ts | Updates ToolsController construction for eval harness. |
| packages/compass-assistant/src/prompts.ts | Makes tool list in context prompt depend on enableAtlasConnectionErrorDebugger. |
| packages/compass-assistant/src/prompts.spec.ts | Updates expected prompt output (currently inconsistent with default flag behavior). |
| packages/compass-assistant/src/components/tool-toggle.tsx | Uses getAvailableTools(...) and preference to render tool list/count. |
| packages/compass-assistant/src/components/tool-toggle.spec.tsx | Updates tool list/count expectations (currently inconsistent with rendered prefs). |
| packages/compass-assistant/src/components/tool-call-message.tsx | Uses getAvailableTools(...) for tool descriptions; adjusts connection chip logic for the new tool. |
| packages/compass-assistant/src/components/tool-call-message.spec.tsx | Updates comments to reflect tool listing source change. |
| packages/compass-assistant/src/compass-assistant-provider.tsx | Threads the new preference into the prompt-building path; introduces an unused/mismatched extra-args type field. |
| packages/atlas-service/src/atlas-service.ts | Adds placeholder debugConnection() API and return type. |
paula-stacho
added
the
feature flagged
5a69443 to
7ccc93f
Compare
8458ee7 to
1c37345
Compare
3b28a13 to
a8d8e63
Compare
| return json; | ||
| } | ||
|
|
||
| async debugConnection( |
There was a problem hiding this comment.
I think so far the rule of thumb was that AtlasService is a generic service that gives you sort of lowish-level fetch methods and the actual fetching with proper paths, schema validation, etc is implemented closer to where it will be used (see rolling indexes service or ai service for example). I think unless you have some strong preference for changing this, I'd stick with that pattern for consistency
There was a problem hiding this comment.
Yeah, I searched for a better place for this outside of the assistant (mostly around connections), but couldn't find one. I was set to have it outside because I figured we might want to add another flow for users who don't want to use assistant, but might be YAGNI.
There was a problem hiding this comment.
I'd just put it close to the tool itself, I think if we're starting to use more of the admin apis going forward, we might consider adding some sort of admin api service generated from openapi definitions for that (but I similarly not sure if it's worth investment at the moment)
| type ExperimentTestGroup, | ||
| } from '@mongodb-js/compass-telemetry'; | ||
|
|
||
| function WithAtlasProviders({ children }: { children: React.ReactNode }) { |
There was a problem hiding this comment.
I kinda feel like every time some core provider like that is added in the tests, we should consider adding this as a default to the testing-library-compass instead, otherwise we end up with a lot of tests reimplementing the same bootstrap code. Not a requirement to change this, but I'd at least consider this. The testing-library-compass package was added exactly for that purpose
Description
Adding the atlas-connection-error-debugger - behind a feature flag. This is just the initial version, missing customized confirmation and response or the actual fetching of the cluster data.
Note: recommend viewing with 'Hide whitespaces'
Checklist
Motivation and Context
Open Questions
Dependents
Types of changes