Contrib.social

Invalidate metadata cache by opening the directory before calling file_exists.

Open on Drupal.org →
Created on 19 January 2024, 11 months ago
Updated 5 February 2024, 11 months ago

Problem/Motivation

Uploads fail about 10% - 30% of the time on kubernetes infrastructure.

file_resup works by using a JS library that chunks the large file into pieces and uploads them to the server in multiple requests. It assembles the chunks in the ~/html/web/sites/default/files/file_resup_temporary directory. This seems to be working fine and dandy. The file always makes it to that directory. Once the browser has said “Oh hey we’re done sending the chunks” Drupal just saves that temporary file as a Drupal managed file in ~/html/web/sites/default/files/2024/01 .

It’s at this point that it fails. I mean it works like 70-90% of the time, but on kubernetes infrastructure pretty regularly Drupal looks for the completed temporary file (which seems to be there) and says

[Thu Jan 18 21:53:32.189151 2024] [php:notice] [pid 101] [client 17.149.225.115:0] The uploaded file is not present.

Steps to reproduce

Just upload a bunch of tiny files. Eventually one will get stuck at 100% and never move from a temporary file to a managed_file.

Proposed resolution

We are running into an edge case of PHP's file_exists because we are switching containers cause this process spans multiple requests. Narayan newton said "Quick changes between webnodes causing Drupal not to detect a new file because of the metadata cache. Resolved by reading the dir first to invalidate the cache". See this stack overflow for more details.

🐛 Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

🇺🇸United States tim bozeman

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024