Skip to content

Comments

Fix the default configs when adding a new provider#1383

Open
deep1401 wants to merge 4 commits intomainfrom
fix/default-configs-providers
Open

Fix the default configs when adding a new provider#1383
deep1401 wants to merge 4 commits intomainfrom
fix/default-configs-providers

Conversation

@deep1401
Copy link
Member

@deep1401 deep1401 commented Feb 24, 2026

Summary by CodeRabbit

  • New Features

    • Added a dedicated "Supported Accelerators" selector for local providers and improved initialization of default accelerator choices.
    • SLURM defaults are now parsed earlier to populate SLURM-specific fields correctly.
  • Bug Fixes

    • JSON Configuration editor is hidden for LOCAL and SLURM provider types.
    • Improved loading, editing, and saving behavior for provider configurations to prevent accidental embedding of accelerator data.

@coderabbitai
Copy link

coderabbitai bot commented Feb 24, 2026

📝 Walkthrough

Walkthrough

Introduces per-provider default accelerator configs and separates supported_accelerators from the raw JSON config. Updates provider creation/edit flows and UI: JSON editor hidden for SLURM and LOCAL, supported accelerators managed separately, and SLURM defaults parsed earlier.

Changes

Cohort / File(s) Summary
Provider Config Modal
src/renderer/components/Team/ProviderDetailsModal.tsx
Introduce DEFAULT_SUPPORTED_ACCELERATORS and use it for initialization; remove embedding/auto-merging of supported_accelerators into provider JSON for non-SLURM types; extract supported_accelerators from loaded configs and strip it from displayed JSON; parse SLURM defaults earlier; initialize local providers with empty JSON and separate supported accelerators; hide generic JSON editor for SLURM and LOCAL types.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I hopped through configs, tidy and bright,
Pulled accelerators out into the light,
SLURM gets parsed, local gets a list,
JSON hides where it's no longer missed. ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Fix the default configs when adding a new provider' directly aligns with the primary objective of the changeset, which focuses on refactoring default configuration handling for providers, including initialization logic for new providers.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/default-configs-providers

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
src/renderer/components/Team/ProviderDetailsModal.tsx (1)

274-290: parsedConfig: any violates the no-any coding guideline.

Define a typed interface instead of relying on any. Since the config shape varies by provider, a discriminated union or a minimal shared type keeps the compiler useful:

♻️ Suggested refactor
+interface ProviderConfig {
+  supported_accelerators?: string[];
+  [key: string]: unknown;   // open for provider-specific fields
+}
+
 const saveProvider = async () => {
   setLoading(true);
   try {
-    let parsedConfig: any;
+    let parsedConfig: ProviderConfig;
     if (type === 'slurm') {
       parsedConfig = buildSlurmConfig();
     } else if (type === 'local') {

As per coding guidelines, "Avoid using any type in TypeScript; define interfaces for all props and API responses to ensure type safety."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Team/ProviderDetailsModal.tsx` around lines 274 -
290, The code declares parsedConfig: any which violates the no-any rule; replace
it with a typed interface or discriminated union that covers provider-specific
shapes (e.g., SlurmConfig for buildSlurmConfig(), LocalConfig for local
provider, and GenericProviderConfig for other providers) and use that type for
parsedConfig in ProviderDetailsModal; ensure the code that assigns parsedConfig
(branches referencing buildSlurmConfig, supportedAccelerators, and the config
prop) narrows the union correctly (via a discriminator like type === 'slurm' |
'local' | 'other' or type guards) so the compiler knows when
supported_accelerators can be assigned and when JSON.parse(config) returns the
expected interface.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/renderer/components/Team/ProviderDetailsModal.tsx`:
- Around line 277-282: When handling type === 'local' in the save path,
parsedConfig is reset to {} which drops any existing fields from the current
config state; instead seed parsedConfig from the existing config (merge config
into parsedConfig) and then set/override supported_accelerators only if
supportedAccelerators.length > 0 so extra keys (e.g. base_url or future fields)
are preserved; update the block that builds parsedConfig for local providers
(referencing parsedConfig, supportedAccelerators and the component's config
state populated by the useEffect) to merge rather than replace.

---

Nitpick comments:
In `@src/renderer/components/Team/ProviderDetailsModal.tsx`:
- Around line 274-290: The code declares parsedConfig: any which violates the
no-any rule; replace it with a typed interface or discriminated union that
covers provider-specific shapes (e.g., SlurmConfig for buildSlurmConfig(),
LocalConfig for local provider, and GenericProviderConfig for other providers)
and use that type for parsedConfig in ProviderDetailsModal; ensure the code that
assigns parsedConfig (branches referencing buildSlurmConfig,
supportedAccelerators, and the config prop) narrows the union correctly (via a
discriminator like type === 'slurm' | 'local' | 'other' or type guards) so the
compiler knows when supported_accelerators can be assigned and when
JSON.parse(config) returns the expected interface.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fce1a03 and ebe5006.

📒 Files selected for processing (1)
  • src/renderer/components/Team/ProviderDetailsModal.tsx

dadmobile
dadmobile previously approved these changes Feb 24, 2026
@deep1401 deep1401 requested a review from dadmobile February 24, 2026 20:44
@deep1401 deep1401 dismissed dadmobile’s stale review February 24, 2026 20:45

Dismissing so you can check again @dadmobile

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

♻️ Duplicate comments (1)
src/renderer/components/Team/ProviderDetailsModal.tsx (1)

285-290: ⚠️ Potential issue | 🟡 Minor

Avoid dropping existing local provider config fields on save.
Editing a local provider with extra config keys will still discard them because parsedConfig is reset to {}.

🛡️ Proposed fix
-        parsedConfig = {};
+        parsedConfig =
+          typeof config === 'string' && config
+            ? JSON.parse(config)
+            : config || {};
         if (supportedAccelerators.length > 0) {
           parsedConfig.supported_accelerators = supportedAccelerators;
         }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Team/ProviderDetailsModal.tsx` around lines 285 -
290, The code in ProviderDetailsModal.tsx resets parsedConfig to {} for type ===
'local', dropping any existing local provider fields; instead preserve and merge
existing config and only set/overwrite supported_accelerators when
supportedAccelerators is non-empty. Update the logic around parsedConfig (the
variable assigned inside the type === 'local' branch) to start from the existing
parsedConfig/object and merge in supported_accelerators (e.g., copy existing
keys and add supported_accelerators) rather than replacing the whole object so
extra config keys are retained on save.
🧹 Nitpick comments (1)
src/renderer/components/Team/ProviderDetailsModal.tsx (1)

210-225: Add isolated tests for default accelerator init and SLURM default parsing.
These behaviors are now central to the add‑provider flow and should be covered in component tests.

As per coding guidelines, "Write unit tests for all utility functions and complex hooks in the frontend" and "Test frontend components in isolation where possible".

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Team/ProviderDetailsModal.tsx` around lines 210 -
225, Add isolated unit tests for ProviderDetailsModal to cover two behaviors:
(1) initialization of supported accelerators by verifying that when
DEFAULT_SUPPORTED_ACCELERATORS has an entry for the provider type the component
calls setSupportedAccelerators with that value (and falls back to an empty array
when absent), and (2) SLURM default parsing by asserting that when type ===
'slurm' and defaultConfig is valid JSON the parseSlurmConfig logic is invoked
(and that parse errors are ignored). Locate tests around the
ProviderDetailsModal component, mock or stub DEFAULT_SUPPORTED_ACCELERATORS,
provide controlled defaultConfig strings, and spy on setSupportedAccelerators
and parseSlurmConfig to assert expected calls and fallbacks.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@src/renderer/components/Team/ProviderDetailsModal.tsx`:
- Around line 285-290: The code in ProviderDetailsModal.tsx resets parsedConfig
to {} for type === 'local', dropping any existing local provider fields; instead
preserve and merge existing config and only set/overwrite supported_accelerators
when supportedAccelerators is non-empty. Update the logic around parsedConfig
(the variable assigned inside the type === 'local' branch) to start from the
existing parsedConfig/object and merge in supported_accelerators (e.g., copy
existing keys and add supported_accelerators) rather than replacing the whole
object so extra config keys are retained on save.

---

Nitpick comments:
In `@src/renderer/components/Team/ProviderDetailsModal.tsx`:
- Around line 210-225: Add isolated unit tests for ProviderDetailsModal to cover
two behaviors: (1) initialization of supported accelerators by verifying that
when DEFAULT_SUPPORTED_ACCELERATORS has an entry for the provider type the
component calls setSupportedAccelerators with that value (and falls back to an
empty array when absent), and (2) SLURM default parsing by asserting that when
type === 'slurm' and defaultConfig is valid JSON the parseSlurmConfig logic is
invoked (and that parse errors are ignored). Locate tests around the
ProviderDetailsModal component, mock or stub DEFAULT_SUPPORTED_ACCELERATORS,
provide controlled defaultConfig strings, and spy on setSupportedAccelerators
and parseSlurmConfig to assert expected calls and fallbacks.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ebe5006 and edf4633.

📒 Files selected for processing (1)
  • src/renderer/components/Team/ProviderDetailsModal.tsx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants