-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
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 |
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. |
@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. |
Can one framework version write different archive versions? |
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. |
This will generally be fixed by updating the the latest toolshed version. We'll have Otherwise, there's not much we can do about it at the moment. |
I have users reporting the following error (with strage line breaks)
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
The text was updated successfully, but these errors were encountered: