fixed yaml file advanced setting not populating issue at model traini…

[sam4coding]

Fix: Advanced Configuration tab not auto-populating when YAML preset is selected

Root Cause: The useEffect hook in
YamlFileEditor.js
had context.uploadedYamlFile in its dependency array, which prevented the YAML content from loading properly when a preset was selected (since uploadedYamlFile doesn't change for presets).

Solution: Removed context.uploadedYamlFile from the dependency array. The effect now correctly triggers whenever trainingConfig or inferenceConfig changes, regardless of whether the config came from an uploaded file or a preset.

Files Modified:

client/src/components/YamlFileEditor.js
(line 331-335)

[samcraftt]

The original issue (#110) is about a specific case where the lucchi++.yaml that's attached isn't auto-populating the advanced config page.

Auto-populating the advanced config page already works for other yaml config files (like those in pytorch_connectomics/configs), but for some reason it doesn't work for the lucchi++.yaml file attached to the issue. I believe it has something to do with the alternate formatting of lucchi++.yaml, but we should be able to handle different, but valid formats.

Also, not sure if the package-lock.json was supposed to change, I ran an npm install in client and nothing changed so maybe if you run a quick npm install it'll undo that.

And you can see instructions in README.md to auto-format your code to handle the linter errors.

[sam4coding]

Description
This PR addresses the issue where uploaded YAML files (specifically from the Lucchi++ / MONAI-style schema) failed to auto-populate the UI "slots" in the Model Training and Inference tabs. It introduces a schema adapter layer and fixes several underlying configuration persistence and API signature bugs.
Key Changes
YAML Schema Adapter: Added utils/yamlSchemaAdapter.js to detect and translate nested, lowercase schemas into the flat-uppercase format required by pytorch_connectomics. Supports cross-platform path splitting (Linux/Windows).
Step 0 Auto-population: Modified YamlFileUploader.js to automatically fill the "Dataset Paths" fields in the UI when a YAML is uploaded, significantly improving user experience.
Storage Standardization: Migrated configuration storage from localStorage to localforage for better consistency. Includes a migration guard to move legacy data on the first mount.
Inference API Fix: Fixed a signature mismatch in ModelInference.js and handled a potential KeyError in the backend model.py regarding the arguments key.
Validation Results
[x] Schema Detection: Confirmed blue toast notification appears for Lucchi++.yaml.
[x] Auto-population: Verified that inputImage, inputLabel, and outputPath are correctly populated in Step 0.
[x] Hyperparameters: Confirmed Batch size, GPUs, and other sliders sync with the uploaded file.
[x] Backend Stability: Verified that the "Start Training" action no longer crashes the backend service due to missing dictionary keys.

[sam4coding]

[akgohain]

i think generally speaking, it's probably not a good idea to hard code lucchi into the codebase, as it is just one of many potential pytc configs for inference and training. in fact, such a config could be applied to any similar mito dataset......double check the implementation throughout the PR to make sure it's in line with the general implementation of the inference/training YAMLs in the parent PytorchConnectomics repo

[akgohain]

basically lucchi should never be referred to throughout the codebase and the implementation of parsing should be generalist for the PytorchConnectomics models

[akgohain]

stuff in the comments. see https://github.com/PytorchConnectomics/pytorch_connectomics for implementation reference

[sam4coding]

Thank you for the guidance, @akgohain. I have completely refactored the yamlSchemaAdapter.js to remove all dataset-specific hardcoding (e.g., 'lucchi') and align with the general implementation of the pytorch_connectomics library.

Key improvements in this update:

Generalist Detection: The parser now identifies schemas based on structural blocks (MODEL, DATASET, SOLVER, etc.) rather than specific dataset names.

Dual-Case Support: Based on a scan of the parent repository, I found that both YACS-style (Uppercase) and Hydra-style (Lowercase) configs coexist. The adapter now supports both patterns seamlessly.

Automatic Adaptation: Standard uppercase configs are passed through directly, while lowercase patterns are adapted to the internal YACS-style requirements of the client.

Schema Labeling: All identified configurations are now categorized simply as standard to ensure the codebase remains dataset-agnostic.

Please let me know if this revised approach meets the project's standards!