Closed (cannot reproduce)
Project:
Webform
Version:
8.x-5.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
9 Mar 2020 at 23:55 UTC
Updated:
25 Jun 2020 at 12:45 UTC
Jump to comment: Most recent
Comments
Comment #2
jrockowitz commentedAny temp file that is not saved to the database will remain in the _sid_ and then be automatically deleted in 5 hours.
Comment #3
cilefen commentedThese files are attached to completed submissions as being in the _sid_ private file directory.
Comment #4
jrockowitz commented@cilefen These 'temp' files should be listed in the 'file_managed' table and via /admin/content/files
Comment #5
cilefen commentedIndeed, they are and they are marked temporary. But what could have gone wrong that prevented them from becoming permanent?
Comment #6
cilefen commented(It looks like cron hasn't been running on an affected site. We'll fix that.)
Comment #7
jrockowitz commentedIf someone uploads a file via a webform, the file is automatically markup as temporary and then they do not submit the form, the temporary file will remain until cron runs.
Comment #8
jrockowitz commentedComment #9
cilefen commentedThey submitted the forms. That is, files attached to submitted forms are in "_sid_".
Comment #10
jrockowitz commentedCan you provide an example webform that can be used to replicate the issue?
Comment #11
cilefen commentedI sent it under a separate cover. The configuration allows drafts, and cron has not been running (although it is configured on the hosting platform to do so—that's a whole separate issue).
Comment #12
cilefen commentedIt turns cron on the affected site may be completing some tasks but not others because it has been dying with this exception.
Comment #13
cilefen commentedYes, the form is huge. I am down to it's either the half-broken cron executions or maybe, hugeness of the form.
Comment #14
cilefen commentedHere's where I am:
Comment #15
cilefen commentedThe affected files were uploaded in a file_managed that is inside a custom_composite, and they are all affected. However, I can't reproduce this by isolating this field in an otherwise empty form:
Comment #16
cilefen commentedWhoops I didn't intend to change the status.
Comment #17
cilefen commentedComment #18
jrockowitz commentedMy only other guess is the size of the webform or the $_POST data is causing issues.
Comment #19
jrockowitz commentedComment #20
cilefen commentedWe are investigating https://docs.acquia.com/acquia-cloud/manage/files/broken/ as a possible cause.