Uploaded files can lose their original filename and collide on retry

[maxesse]

Summary

An uploaded file can be stored successfully and remain downloadable, while the sandbox receives it under its opaque storage ID instead of the original filename. Code generated from the attachment context then opens the advertised original path and gets FileNotFoundError. A subsequent execution can fail earlier with a duplicate/conflicting input destination because both references resolve to the same storage-ID filename.

This was observed after updating to fe9fe33971d252825c0a30b10cb22c277c31e52a in a hardened KVM deployment using the file server with an S3-compatible Flexify endpoint backed by Azure Blob Storage.

Observed behavior

A workbook uploaded as Sample_-_Superstore.xlsx was accepted by the file server:

File uploaded successfully: Sample_-_Superstore.xlsx

The upload was registered correctly and the object remained present and downloadable. However, the file-server metadata endpoint returned the opaque object basename as both the object name and originalFilename:

{
  "name": "<storage-session>/<file-id>.xlsx",
  "originalFilename": "<file-id>.xlsx",
  "size": 1374225,
  "contentType": "application/octet-stream",
  "readOnly": false
}

The runner consequently logged:

Downloaded file: <file-id>.xlsx

The first execution then failed because /mnt/data/Sample_-_Superstore.xlsx did not exist. On retry, execution was rejected with:

Conflicting input destinations: <file-id>.xlsx and <file-id>.xlsx

The same duplicate-destination errors are occurring for other filenames and users, so this is not specific to the workbook.

Expected behavior

The sandbox should expose the uploaded file at its requested/original relative filename, for example:

/mnt/data/Sample_-_Superstore.xlsx

A retry containing the same logical file should not produce two colliding input destinations.

Likely failure path

file-server writes the original filename into S3 user metadata. When that metadata is absent or not returned by the S3-compatible backend, the download route falls back to path.basename(objectName), which is the opaque storage ID. Job.downloadAndWriteFile() treats the response Content-Disposition filename as authoritative and replaces the caller-provided destination with that fallback.

This makes an object-store metadata interoperability problem visible as an incorrect sandbox filename. The returned reference can then be combined with the original reference on a later execution, producing the duplicate-destination rejection.

Possible defenses include:

• Fall back to the requested file.name when original-filename metadata is unavailable, rather than returning the opaque object basename as authoritative.
• Persist filename metadata independently of optional S3 user metadata.
• Deduplicate repeated references to the same object and destination before dispatch.

Relationship to #40

This is related to #40 because both affect uploaded file references, but it does not appear to be the same bug. In this case:

• the upload registration succeeded;
• no upload_missing or authorization failure occurred;
• the file server found and streamed the object;
• the runner downloaded the bytes successfully.

The failure is the loss/fallback of the original filename after successful authorization and download, followed by a duplicate destination on retry.