fix: detect uploaded file type for uppercase file extensions

[sanidhyasin]

Description

Uploading a file whose name ends with an uppercase extension (e.g. report.PDF) does not work — the file is processed by the plain-text loader instead of the correct one (the PDF loader), producing garbled/empty content. Renaming the file to a lowercase extension (report.pdf) works around it.

Root cause

mapExtToInputField (in packages/components/src/utils.ts) matches the extension with a case-sensitive switch. path.extname('report.PDF') returns '.PDF', which does not match the '.pdf' case and falls through to the default 'txtFile', so the wrong file loader input field is selected.

The MIME-type fallback in createFileAttachment that should have caught this was also broken by a copy-paste bug: in the else if (fileInputFieldFromMimeType !== 'txtFile') branch it assigned fileInputFieldFromExt (which is always 'txtFile' in that branch) instead of fileInputFieldFromMimeType, so the MIME-derived field was never used.

Changes

• mapExtToInputField: lowercase the extension before matching, making file-type detection case-insensitive. This is the shared helper used by full file upload, the document store, and chat uploads, so the fix applies consistently across all of them.
• createFileAttachment: use fileInputFieldFromMimeType in the MIME-type fallback branch so the field derived from the MIME type is actually selected when the extension is unrecognized.
• Added unit tests for mapExtToInputField covering lowercase, uppercase, mixed-case, and unknown extensions.

Note: the upload security validator (validateMimeTypeAndExtensionMatch) already normalizes the extension to lowercase, so uppercase files were not rejected — only mis-routed. No change to validation behavior.

Fixes #5029

How to reproduce / verify

1. Enable full file upload on a chatflow.
2. Upload a PDF whose filename ends in .PDF (uppercase).
3. Before: the content is parsed as plain text (broken). After: it is parsed by the PDF loader, same as a .pdf file.

[gemini-code-assist]

Code Review

This pull request introduces case-insensitivity to the mapExtToInputField utility function by converting the input extension to lowercase, accompanied by comprehensive unit tests. It also fixes a bug in createFileAttachment where the fallback assignment incorrectly used the extension-based field instead of the mime-type-based field. Feedback suggests adding a nullish check (ext == null) in mapExtToInputField to prevent potential runtime TypeError crashes if the extension is null or undefined.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[sanidhyasin]

Thanks for the review. Addressed in abc7ea9.

I guarded the nullish case with optional chaining (ext?.toLowerCase()) rather than an early return. The suggested if (ext == null) return; would return undefined, which changes the return type to string | undefined and would break the callers that compare against the string default — e.g. in createFileAttachment:

if (fileInputFieldFromExt !== 'txtFile') {
    fileInputField = fileInputFieldFromExt   // would become `undefined`
}

With optional chaining, a null/undefined/empty ext simply misses every case and falls through to the existing default: return 'txtFile', so the function keeps its string contract and nullish input maps to the same default as an unrecognized extension. Added tests covering '', undefined, and null, and updated the JSDoc to mark the parameter optional.