| Issue Number | 734 |
|---|---|
| Summary | Sporadic failure posting meeting files |
| Created | 2023-02-10 10:50:45 |
| Issue Type | Bug |
| Submitted By | Kline, Bob (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2023-02-10 18:20:26 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/oceebms/issue.338403 |
In a seemingly random way, posting files to meetings sometimes results in the error message
The specific file [filename] could not be uploaded. This value should be of the correct primitive type.
Characteristics of the bug:
it doesn't happen all the time
it happens a greater percentage of the time for some users than others (Victoria reports that when she posts several files in a single action, some of them usually fail, whereas one-at-a-time uploads succeed; for me, most of the time multiple-file post actions succeed, though failures for some of the batch are not rare)
the failures (so far) seem to be unrelated to file type or size
it does not seem to make any difference whether the files are dragged or selected
I have done quite a bit of research to find reports of this problem. Nothing turns up specifically related to the behavior we're seeing. In all the other bug reports I've been able to find, there was some condition which was causing the problem which is not present in our cases (for example, SVG file uploads were failing if there was no plugin to calculate its dimensions, or date or integer fields got that error message if the value was missing), and significantly: for all of those bug reports the behavior was not sporadic: for a given installation, if the condition was present, the error always appeared. In our case, by contrast, it seems that the error occurs some of the time and does not occur the rest of the time under the same conditions.
We could
replace the file posting interface on this form with a custom field which lets us add one file at a time and remove one file at a time (as in the production system); or
use the existing interface as it currently behaves, modifying behavior to minimize failures to the extent possible, hoping that the cause of the bug will eventually be discovered and corrected; or
defer the deployment until we can find out what's causing the problem and fix it.
Added watchers.
~vshields or ~juther when you get a chance could you try attaching files to meetings on https://ebms.rksystems.com? No promises or guarantees, but I may have found a way around this problem.😉
(Also, on a weakly-related note, we may have discussed this before, but if we did I don't remember the discussion: I was reminded by this fire drill that the production system allows a much more extensive set of file types to be uploaded (txt doc pdf docx ppt pptx xls xlsx jpg jpeg gif bmp png tiff mpg mpeg mp4 3gp avi htm html) whereas the new system only allows the types which have actually been uploaded at least once for this field (pdf rtf doc docx pptx). Is what I've done in the new system OK? Do you actually want the full list allowed by the old system? Something in between? Or possibly even more restrictive than what I have now?)
It seems to be working well for me! I created a new meeting and uploaded a few files as myself, then edited the event to upload a few more as Test Board Manager. It worked well each time, and I also tested the ability to download all files for a meeting under both roles (and as Test Board Member) and that went smoothly as well. Thank you!
I can think of at least a few occasions where Board members have been working in Excel files, so we might want to add xlsx.
Done (on https://ebms.rksystems.com) though on this particular form the board members aren't allowed to post anything.
Installed on https://ebms4-dev.nci.nih.gov.
Verified on ebms4-dev.
Verified on PROD.
Elapsed: 0:00:00.000781