There's a potentially massive number of requests on this common resource due to the nature of the queries, joins, and general reshuffling of the data.
Probably a good idea to either localise this data, or checkpoint after the join to reduce network traffic. It's only a small table, so writing into each batch is fine
Case: 2 runs were using this central table, then one of the runs was restarted. That burden was enough to crash the run on the basis of overloading the GCP object bandwidth cap
See https://batch.hail.populationgenomics.org.au/batches/422683/jobs/2
There's a potentially massive number of requests on this common resource due to the nature of the queries, joins, and general reshuffling of the data.
Probably a good idea to either localise this data, or checkpoint after the join to reduce network traffic. It's only a small table, so writing into each batch is fine
Case: 2 runs were using this central table, then one of the runs was restarted. That burden was enough to crash the run on the basis of overloading the GCP object bandwidth cap