Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors due to wrong archive version #53

Closed
bernt-matthias opened this issue Jan 31, 2024 · 6 comments
Closed

Errors due to wrong archive version #53

bernt-matthias opened this issue Jan 31, 2024 · 6 comments
Assignees

Comments

@bernt-matthias
Copy link
Contributor

I have users reporting the following error (with strage line breaks)

Unexpected error loading arguments in
q2galaxy: /gpfs1/data/galaxy_server/g
alaxy/database/files/000/575/dataset_
575964.dat was created by 'QIIME
2023.5.1'. The currently installed
framework cannot interpret archive
version '6'.

I guess there is some versioning in the qza files and the users used a wrong one.

I think the metadata stored in the galaxy datatype https://github.com/galaxyproject/galaxy/blob/29290dea0cc78566947fc871fcc5634f11b4ee48/lib/galaxy/datatypes/qiime2.py#L67 can be used by adding a metadata validator https://docs.galaxyproject.org/en/master/dev/schema.html#tool-inputs-param-validator to data parameters that take qza input

@Oddant1
Copy link
Member

Oddant1 commented Jan 31, 2024

This is expected behavior on our end. In QIIME 2 2023.5 we changed the provenance archive version from 5 to 6 because we made breaking changes to provenance to add support for output collections. Artifacts produced in QIIME 2 2023.5 and on are not backwards compatible with QIIME 2 releases older than 2023.5, but older artifacts are of course forwards compatible.

We should be able to do that validation, but whether the input is valid or not will depend on which version of QIIME 2 a given galaxy deployment is running. Is it possible for the validator to get clever and determine at run time what it can and cannot accept, or do we need to do it at tool creation time?

Given the versions of QIIME 2 realistically in use it's currently either going to be <=5 or <=6

@Oddant1 Oddant1 self-assigned this Jan 31, 2024
@bernt-matthias
Copy link
Contributor Author

The validator has access to the metadata defined here, i.e. the format version. So I guess the supported format version (bound) needs to be set at tool creation time.

@Oddant1
Copy link
Member

Oddant1 commented Feb 6, 2024

@bernt-matthias We don't actually have the archive version stored on the metadata there. We have the version of the framework that was used to produce the artifact, so in order for this validator to work we're going to need to add another field to that metadata.

@bernt-matthias
Copy link
Contributor Author

Can one framework version write different archive versions?

@Oddant1
Copy link
Member

Oddant1 commented Feb 6, 2024

No, a given framework version will always write the same archive version, but it can read all archive versions up to and including the one it writes. Old artifacts are compatible with newer versions of QIIME 2, but new artifacts may not be compatible with older versions of QIIME 2.

We can't just use the framework version to determine compatibility though because compatibility isn't broken every time we update QIIME 2, it's only broken every time we create a new archive version. Last time we did that was 2023.5 the last time before that was October of 2018. So artifacts produced by versions of QIIME 2 from 2018.11 to 2023.2 all use archive version 5 meaning you could in principle use an artifact produced by QIIME 2 2023.2 as an input to QIIME 2 2018.11.

We MIGHT be able to fudge things a bit by knowing what version of QIIME 2 we are using and what archive version that supports, but at this point the next release of q2galaxy and the galaxy-tools will support up to version 6. We would need to re-render the old pre-archive version 6 tools. There's no telling when archive version 7 will be a thing, but it likely won't take 5.5 years like the last bump did.

@ebolyen
Copy link
Member

ebolyen commented May 30, 2024

This will generally be fixed by updating the the latest toolshed version. We'll have 2024.5 going up next week (which also will support archive 6).

Otherwise, there's not much we can do about it at the moment.

@ebolyen ebolyen closed this as completed May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants