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

Evaluate the use of hard-coded exit status as a fallback for mtbseq statuses #63

Open
abhi18av opened this issue Apr 22, 2022 · 5 comments

Comments

@abhi18av
Copy link
Member

Given the recent experience with files transfers on clusters, the errors raised by GATK tool were ignored as part of the current solution

Ideally we capture this via a shell construct (maybe from bin folder) and throw exit 1

##### ERROR A USER ERROR has occurred (version 3.8-0-ge9d806836): 
@abhi18av
Copy link
Member Author

@Mxrcon , before making further progress on #63 - let's iron out the details here and then invest further time there.

...
...
    1>>.command.out \
    2>>.command.err \
    || true               

The necessity for the above snippet is to counter the irregularities we have seen in the MTBseq exit status and how Nextflow interpreted those in terms of the workflow.

One of the possibilities of these errors is due to the absence of logs (which the proposed bash script #65 addressed) but perhaps we can also address other such as parsing the log files generated by MTBseq within a process and check if there's any presence of ERROR etc.

What are you thoughts regarding other use-cases we can cover?

@Mxrcon
Copy link
Member

Mxrcon commented Apr 24, 2022

@abhi18av I Don't like the idea of creating a new process to parse log, in my opinion every process should check the logs in the end of the job, so this way if a process causes an error we shouldn't continue using it outputs.

We already saw a lot of times when some samples didn't worked and the workflow continued using the outputs and failed into the next process due the missingness of input files, I think that our main work should be focused on solving this error cases.
Maybe using a bash script to check the .command.out will be too much meta evaluation of logs, but seems to be a good alternative as it'd capture every output of the commands.

@abhi18av
Copy link
Member Author

Thanks for sharing your thoughts - I think we might be out of sync a bit here, perhaps we discuss this again when we connect.

@Mxrcon
Copy link
Member

Mxrcon commented Apr 26, 2022

sure! makes complete sense!

@abhi18av
Copy link
Member Author

Adding a suggestion by Davi, to capture the exit code manually (in a non-NF dotfile)

https://www.cyberciti.biz/faq/bash-get-exit-code-of-command/

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

Successfully merging a pull request may close this issue.

2 participants