Immediately unlink Rack::Multipart temporary files
Rack writes files from multipart/form-data requests to disk in a temporary file. Rack includes a middleware to clean these up - Rack::TempfileReaper - but that won't withstand a process being sent SIGKILL. To handle that case, we can immediately unlink the created temporary file, which means it will be removed once we're done with it or the current process goes away. For development mode and test mode, we have to ensure that this new middleware is before Gitlab::Middleware::Static, otherwise we might not get the chance to set our own middleware. With direct upload configured, GitLab mostly doesn't accept multipart/form-data requests in a way where they reach Rack directly - they typically go via Workhorse which accelerates them - but there are cases where it can happen, and direct upload is still only an option. To test this manually, we can set `$GITLAB_API_TOKEN_LOCAL` to a personal access token for the API in the local environment, `$PATH_TO_FILE` to be a path to a (preferably large) file to be uploaded, and break the actual saving of uploads (in the default case with GDK, stop Minio): curl -H "Private-Token: $GITLAB_API_TOKEN_LOCAL" \ -F "file=@$PATH_TO_FILE" \ http://localhost:3000/api/v4/projects/1/uploads Once the upload is finished and the request fails, we'll see the file we uploaded in `$TMPDIR`: $ ls -l $TMPDIR/RackMultipart* | awk '{ print $5, $8 }' 952107008 17:40 With this change, that won't happen: we'll see the file created and immediately unlinked, so no matter what happens, it won't stick around on disk. (This specific test case is handled by Rack::TempfileReaper in later versions of Rack, but it still depends on manual cleanup.)
Showing
Please register or sign in to comment