File uploads should preserve the original filename when possible

[bjester]

Observed behavior

When requesting a file upload URL from Studio, Ricecooker does utilize the original file name, but that is eventually discarded, meaning the filename for cheffed files will default to file

the issue is that ricecooker's implementation of the file upload URL stuff [...] creates the file object to get the upload URL, but then an entirely new file object gets created during the channel upload, so that data gets discarded.

Expected behavior

Ricecooker should use preserve the filename

User-facing consequences

These files end up showing Unknown filename to the end user.

Context

learningequality/studio#4814

Looking at the following bit of code it does appear Ricecooker passes the filename along in its initial request for an upload URL, but according to the above quote, that gets discarded

ricecooker/ricecooker/managers/tree.py

Lines 155 to 166 in b694f3d

	"name": file_data.original_filename or file_data.get_filename(),
	"file_format": file_data.extension,
	"preset": file_data.get_preset(),
	"duration": file_data.duration,
	}
	# Workaround for a bug in the Studio upload URL endpoint, whereby
	# it does not currently use the passed in file_format as the default
	# extension.
	name, ext = os.path.splitext(data["name"])
	if not ext:
	data["name"] = "{}.{}".format(name, data["file_format"])
	url_response = config.SESSION.post(config.get_upload_url(), json=data)

[codesage01]

can i contribute to this?

[MisRob]

Hi @codesage01, welcome and thanks for volunteering! For several first contributions, please find an unassigned issue labeled as 'help wanted' - that's how we label issues that we have identified as suitable for volunteers. After having long-term experience with our codebases, if you're still interested in this one, you're welcome to message us and we are happy to consider.

[codesage01]

ok i will do ... further

[rtibbles]

As I have been messing about with the File classes in ricecooker, I'm also not actually sure that this attribute ever gets set, except for Graphie files. It's most odd. I am making updates so that this info is persisted, so that we can get it into Studio in the first place, and then this issue can be resolved.

[rtibblesbot]

Triage note: this looks like it may already be resolved by the file-processing pipeline refactor. Flagging before doing implementation work, since there may be nothing left to fix.

The do_file_upload code the issue points at already prefers the original filename:

"name": file_data.original_filename or file_data.get_filename(),

The original bug was that file_data.original_filename was never populated — the pre-pipeline File classes didn't capture the source filename, so name fell back to the checksum-based filename and Studio showed "Unknown filename". The described "a new file object gets created during channel upload, so that data gets discarded" no longer applies: TreeManager.file_map now holds the same processed File objects that both request the upload URL and get uploaded.

In the current code, original_filename is plumbed end-to-end:

• Transfer handlers extract it during download — from Content-Disposition/URL for remote files and the basename for local files (utils/pipeline/transfer.py).
• DownloadFile.process_file() and ContentNode._process_uri() copy it from the pipeline metadata onto the File object.
• do_file_upload() sends it as name, and File.file_dict() includes it in the channel structure upload.

This is covered by tests in tests/pipeline/test_transfer.py, which assert the extracted original_filename for video, document, ogv, pdf, vtt, mp3, and spreadsheet inputs.

Could a maintainer confirm whether this is still reproducible on a recent ricecooker release? If so, a specific repro (file type / how the file is added to the node) would help pinpoint the remaining gap. Otherwise this can likely be closed.

[rtibblesbot]

The bot has been waiting for a response for 2 hour(s). It will resume automatically when someone replies.

[rtibbles]

The issue is that while that original filename does get passed to the file upload URL, the file object that is created during that process is orphaned, and a new one gets created in the internal API workflows. This is in contrast to the Studio frontend usage of the same API endpoint where the created file object is kept and it is edited to point at the relevant content node object.

To handle this, we would need a way of passing the pre-existing file objects in the ricecooker upload payload - or, more ambitiously, simply let ricecooker use the Studio sync endpoint for its edits and have it build the tree in the same way as the frontend client.

[rtibblesbot]

The bot has been waiting for a response for 2 hour(s). It will resume automatically when someone replies.