You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A clear and concise description of what the bug is.
The question is, in fact, how it handles valid extra header lines?
By error, a file was uploaded which had twice the same header, except for the organism (or assembly). The "second" header was wrong, and upload failed, as if information from the second header was also used. In this case, I would have expected that all comment lines after the "true" header are ignored.
This is an unlikely scenario, but I believe we should go though the importer tests to make sure we do cover general variations on header format and length. In particular, we need to think if we should (and how to) handle the newly added tag #internal_source, which is not meant to be part of the EUF specifications.
The text was updated successfully, but these errors were encountered:
A clear and concise description of what the bug is.
The question is, in fact, how it handles valid extra header lines?
By error, a file was uploaded which had twice the same header, except for the organism (or assembly). The "second" header was wrong, and upload failed, as if information from the second header was also used. In this case, I would have expected that all comment lines after the "true" header are ignored.
This is an unlikely scenario, but I believe we should go though the importer tests to make sure we do cover general variations on header format and length. In particular, we need to think if we should (and how to) handle the newly added tag
#internal_source
, which is not meant to be part of the EUF specifications.The text was updated successfully, but these errors were encountered: