Open jmarshall opened 1 month ago
Hi @jmarshall, the team talked about this issue in our standup today. We had some concerns about appropriateness of using this table as a long term storage area for larger metadata, and the likely developer effort and system downtime to perform the migration. So we currently don't plan on prioritizing this in the immediate future, but do let us know if you have any concerns about that - or if it ends up being impossible for you to work around this - and we might be able to reconsider (or maybe come up with alternative solutions). Thanks!
We recently encountered a batch submission that eventually failed after numerous errors like this one — but nonetheless submitted a new batch containing zero jobs.
The corresponding server-side error was
coming from the
INSERT INTO job_attributes …
query ininsert_jobs_into_db()
.We write a list of the samples being processed as a job attribute, and it turned out that for at least some of the jobs of this batch this list had grown to longer than 64K of text.
The
job_attributes.value
database field is of type TEXT, which limits each individual attribute to 64KiB bytes.While writing a long list of sample ids as an attribute may or may not be a great idea :smile: it is fair to say that 64K is not a large maximum for user-supplied data here in the 21st century!
It may be worth adding a database migration to change the
job_attributes.value
column type (and perhaps also that ofjob_group_attributes.value
) from TEXT to MEDIUMTEXT, which would raise the limit to 16 MiB bytes (at, it appears, a cost of 1 byte per row).