Show the variants that have problem in error message.

[EstelleDa]

Hi @bencap , I choose to merge to your base-editor-data. Feel free to change it to any other branch that you think is better. Mine is based on the base-editor-data branch.

[bencap]

Thanks for breaking these out, this will be really useful for users I think. I had two suggestions:

• It's true that the prior code created sets, but I would use a list or tuple here now since our goals have changed a little. We'd like to be able to tell the user about every error that we find, and to do that we should preserve variants even when they aren't unique. It would be confusing for the user to receive an error like 'validation errors found: line 1, line 2', only for them to fix those errors and have identical errors in lines 3 and 4.
• I would make use of the triggers part of the ValidationError class, here is an example:

  mavedb-api/src/mavedb/lib/validation/dataframe.py

  Lines 447 to 451 in cbacd63

  	# format and raise an error message that contains all invalid variants
  	if len(invalid_variants) > 0:
  	raise ValidationError(
  	f"encountered {len(invalid_variants)} invalid variant strings.", triggers=invalid_variants
  	)

  . This class will be used by the UI to display the triggers as a list of errors automatically. We can combine this with the enumerate function to provide granular feedback to the user:

invalid_accessions = {f"accession identifier {str(v).split(":")[0]} from row {idx}, variant {v} not found" for idx, v in enumerate(variants) if str(v).split(":")[0] not in targets}
if invalid_accessions:
    raise ValidationError(
        f"variant column '{column.name}' has invalid accession identifiers; "
        "{len(invalid_accessions)} accession identifiers present in the score file were not added as targets.",
        triggers=invalid_accessions
    )

Now, we provide a useful top level error message within the validation error itself in addition to helpful individual errors that will help the user fix the overall error. I only commented on this one, but the same principal should apply for the other validation checks as well.

[bencap]

We should be able to do the same thing as above for these checks as well.

[bencap]

Thanks Estelle I looked at the changes you made and they looked good. I'm not sure what happened to the branch though. Would you be able to rebase off of release-2025.2.0 when you get a chance? After that I can take a final look and we can finish it up.

[EstelleDa]

Thanks Ben! No idea why these weird conflicts happened. I have merged release-2025.2.0 to it.

[bencap]

Thanks Estelle, looks good besides the one suggestion I noted which was probably a rebasing issue.

[EstelleDa]

Thanks Ben! I think so.