ReactionMechanismGenerator / ReactionMechanismGenerator/ARC
Reaction label is not validated when reactants/products are given, causing a late IndexError in flip_reaction
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 51
- Forks
- 25
- Avg merge
- 4d 5h
- Merged PRs (30d)
- 15
Description
Describe the bug
If a reaction is given both an explicit label and explicit reactants/products, the label is never validated. ARC accepts the input, starts the project, and fails later inside family determination with a bare IndexError that says nothing about labels:
File "arc/reaction/reaction.py", line 582, in determine_family
product_dicts = self.product_dicts
File "arc/family/family.py", line 525, in get_reaction_family_products
flipped_rxn = rxn.flip_reaction(report_family=False)
File "arc/reaction/reaction.py", line 389, in flip_reaction
reaction_dict['label'] = self.arrow.join([label_splits[1], label_splits[0]])
IndexError: list index out of range
The check already exists — it is just on the other branch. In set_label_reactants_products:
if not len(self.reactants) or not len(self.products):
if self.label:
if self.arrow not in self.label:
raise ReactionError(f'A reaction label must contain an arrow ("{self.arrow}")')
...
That guard only runs when the reactants and products are absent. When they are supplied, the whole block is skipped, and the later
if not self.label:
self.label = self.arrow.join(...)
does not fire either, because a label is present. The label therefore survives unvalidated until flip_reaction splits on the arrow and indexes [1].
How to reproduce
project: demo
species:
- label: R
smiles: '[CH2]CC'
- label: P
smiles: 'C[CH]C'
reactions:
- label: my_reaction # no arrow, and reactants/products are given below
reactants: [R]
products: [P]
ARC starts normally, prints the levels of theory, and then raises the IndexError above. With the label line removed it works, because ARC builds the label itself.
Expected behavior
First of all, we should decide if we allow users to not use <=> in the reaction label. If we do not, we would ideally want the fail at input parsing with the message that already exists, rather than partway through the run. Two options, either of which is a small change:
- Move the arrow check out of the
if not len(self.reactants) or not len(self.products)branch so it applies to any user-supplied label. - Have
flip_reactionrebuild the label fromr_species/p_speciesinstead of string-splitting the existing one. That is more robust anyway, since the label is cosmetic once the species are known.
The reason this is worth more than a nicer traceback is timing: on a queueing cluster the failure surfaces after the project directory is created and the first jobs are being prepared, so the user finds out minutes later and from a message that does not name the cause. A label is exactly the kind of thing worth rejecting at parse time.
Installation information
- ARC
main@a24e13b0 - Python 3.14, Linux, PBS
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in arc/reaction/reaction.py, focusing on set_label_reactants_products and flip_reaction, then reproduce the YAML example from the issue. Ensure a supplied label without the required arrow is rejected during input parsing with the existing ReactionError message, before project setup or family determination.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100