Add a few additional failures to our notes doc #8980
Conversation
|
at some point in our notes we added |
| 1. Clean up the BQ dataset manually by deleting it and recreating it fresh | ||
| 1. Make sure to keep the call caching on and run it again | ||
| 1. Ingest failure with error message: `A USER ERROR has occurred: Cannot be missing required value for `___ |
There was a problem hiding this comment.
Is the error message really "Cannot be missing required value for" ? Just seems like an improperly formed sentence
| 1. Ingest failure with error message: `A USER ERROR has occurred: Cannot be missing required value for `___ | ||
| 1. (e.g. alternate_bases.AS_RAW_MQ, RAW_MQandDP or RAW_MQ) | ||
| 1. This means that there is at least one incorrectly formatted sample in your data model. Confirm your GVCFs are reblocked. If the incorrectly formatted samples are a small portion of your callset and you wish to just ignore them, simply delete the from the data model and restart the workflow without them. There should be no issue with starting from here as none of these samples were loaded. |
There was a problem hiding this comment.
You could link here that the full list of required information in a GVCF to work in GVS is here:
https://github.com/broadinstitute/gatk/blob/ah_var_store/scripts/variantstore/beta_docs/run-your-own-samples.md#gvcf-annotations
| 1. (e.g. alternate_bases.AS_RAW_MQ, RAW_MQandDP or RAW_MQ) | ||
| 1. This means that there is at least one incorrectly formatted sample in your data model. Confirm your GVCFs are reblocked. If the incorrectly formatted samples are a small portion of your callset and you wish to just ignore them, simply delete the from the data model and restart the workflow without them. There should be no issue with starting from here as none of these samples were loaded. | ||
| 1. Extract failure with OSError: Is a directory. If you point your extract to a directory that doesn’t already exist, it will not be happy about this. Simply make the directory and run the workflow again. |
There was a problem hiding this comment.
| 1. Extract failure with OSError: Is a directory. If you point your extract to a directory that doesn’t already exist, it will not be happy about this. Simply make the directory and run the workflow again. | |
| 1. Extract failure with OSError: Is a directory. | |
| 1. If you point your extract to a directory that doesn’t already exist, the workflow fails. Make the directory and run the workflow again. |
I'm surprised this is an error the workflow can run into because our documentation suggests people get the workspace bucket and then add a subdirectory to that based on where they want the callset written. Usually that bucket doesn't actually already exist.. Am I misunderstanding your description of this error?
| 1. Ingest failure with: `Lock table error` | ||
| 1. This means that the lock table has been created, but that the ingest has failed soon after or that perhaps during manual cleanup from another failure, some underlying data was deleted | ||
| 1. The lock table can simply be deleted -- `sample_id_assignment_lock` -- and the ingest can be kicked off again |
There was a problem hiding this comment.
We don't talk about the lock table anywhere else in our documentation. I think this will need more detail to be clear to most people. Where is the lock table? How do they find it and delete it? If it picks up where ingest left off, let's reassure them of that here.
| 1. Extract failure with OSError: Is a directory. If you point your extract to a directory that doesn’t already exist, it will not be happy about this. Simply make the directory and run the workflow again. | ||
| 1. Ingest failure with: `Lock table error` | ||
| 1. This means that the lock table has been created, but that the ingest has failed soon after or that perhaps during manual cleanup from another failure, some underlying data was deleted |
There was a problem hiding this comment.
Given the lock table hasn't been mentioned in any of our documentation, I'd reword this to something like
"This error is describing an issue found with one of the tables in the GVS BigQuery dataset called the 'lock table'. It indicates that the lock table has been created, but that the ingest failed soon after or that during manual cleanup from another failure, some underlying data was deleted and now the table is in a broken state."
|
Generally, could you add sections for failures in the other high level steps of GVS? Or if GVS fails in any step besides ingest does the user need to start over from scratch? It'd be great to indicate that ie "If your workflow fails in any step after ingest, unfortunately you will need to delete your BigQuery dataset and start from the beginning." ? |
| 1. Ingest failure: There is already a list of sample names. This may need manual cleanup. Exiting. | ||
| 1. Clean up the BQ dataset manually by deleting it and recreating it fresh | ||
| 1. Make sure to keep the call caching on and run it again |
There was a problem hiding this comment.
Looks like call caching specifically needs to be off for this to be successful, based on recent user error. I am going to bet that's true for both this error and the max id is 0 error.
no automated testing needed--just documentation edits