ReactionMechanismGenerator / ReactionMechanismGenerator/ARC

Reaction label is not validated when reactants/products are given, causing a late IndexError in flip_reaction

Open Beginner friendly
#1,043 0 comments 0 reactions 0 assignees View on GitHub

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:

  1. 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.
  2. Have flip_reaction rebuild the label from r_species/p_species instead 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.