[Bug] Issues arising from tool_instance_name implementation: Parameter loading failure and command generation errors

[hjn0415a]

The introduction of tool_instance_name to support multiple instances of the same TOPP tool (e.g., duplicate IDFilter calls) has caused a side effect when executing the save_parameters method.

Specifically, during the execution of the save_parameters loop, the tool_instance_name is being passed into the create_ini method. This results in an invalid tool name causing create_ini to fail.

for tool in current_topp_tools:
            if not self.create_ini(tool):
                # Could not create ini file - skip this tool
                continue

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Parameter error when using input_TOPP multiple times for the same TOPP tool. #302

🔗 Related PRs

#327 - refactor: extract INI creation into shared ParameterManager.create_ini() [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[hjn0415a]

I'm currently testing on the copilot/fix-tool-instance-name-issue branch.

I assumed that loading an .ini file would bring up the parameter configuration window in the Configure tab,
so I thought we would need separate .ini files for IDFilter-lenient and IDFilter-strict.
However, it seems that only a single IDFilter.ini file is being created.

Is the paramter configuration UI actually generated based on the values from params.json?