Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/meteor/client/views/room/composer/messageBox/MessageComposerFileLoader.tsx">

<violation number="1" location="apps/meteor/client/views/room/composer/messageBox/MessageComposerFileLoader.tsx:22">
P2: `...props` currently overrides the loader animation class. Merge the incoming `className` and apply it after the spread so the spinner animation is preserved.</violation>
</file>

<file name="apps/meteor/app/ui/client/lib/ChatMessages.ts">

<violation number="1" location="apps/meteor/app/ui/client/lib/ChatMessages.ts:127">
P2: Uploads are cleared before checking whether the message can be edited, which can discard pending files on failed edit attempts.</violation>
</file>

<file name="apps/meteor/client/views/room/body/UploadProgress/UploadProgressIndicator.tsx">

<violation number="1" location="apps/meteor/client/views/room/body/UploadProgress/UploadProgressIndicator.tsx:24">
P2: Progress percentage is averaged using completed uploads while the label count only includes active uploads, producing misleading progress values.</violation>
</file>

<file name="apps/meteor/tests/e2e/fixtures/responses/mediaResponse.ts">

<violation number="1" location="apps/meteor/tests/e2e/fixtures/responses/mediaResponse.ts:3">
P2: Escape the dot in the `rooms.media` URL matcher so `waitForResponse` only resolves for the intended endpoint.</violation>
</file>

<file name="apps/meteor/tests/e2e/file-upload.spec.ts">

<violation number="1" location="apps/meteor/tests/e2e/file-upload.spec.ts:122">
P1: The max-files test validates the wrong file name (`number6.png`), so it can pass without actually verifying that the 11th upload is rejected.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/processMessageUploads.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/processMessageUploads.ts:61">
P2: Memory leak: the blob URL created by `URL.createObjectURL` is never revoked after the image dimensions are read. Add `URL.revokeObjectURL(dataURL)` in both the `onload` and `onerror` callbacks of `getHeightAndWidthFromDataUrl`.</violation>
</file>

<file name="apps/meteor/tests/e2e/e2e-encryption/e2ee-file-encryption.spec.ts">

<violation number="1" location="apps/meteor/tests/e2e/e2e-encryption/e2ee-file-encryption.spec.ts:135">
P2: Capture the composer files after `dragAndDropTxtFile()` so the readonly assertion actually checks the newly added (blocked) file.</violation>
</file>

<file name="apps/meteor/tests/e2e/page-objects/fragments/composer.ts">

<violation number="1" location="apps/meteor/tests/e2e/page-objects/fragments/composer.ts:33">
P3: Use `exact: true` for this name-based button locator to avoid matching multiple files with similar names.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/uploadFiles.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/uploadFiles.ts:67">
P2: The `performContinuously('uploading')` action is started unconditionally but is never stopped in this file. If all file encryptions fail (returning `null`), no uploads are added to the store, so `processMessageUploads` exits early without calling `action.stop('uploading')`, leaving the typing/activity indicator stuck on 'uploading'. Move the `stop` call into a `finally`-like position after `Promise.allSettled` to cover this path.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/sendMessage.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/sendMessage.ts:31">
P2: File upload messages now bypass `onClientBeforeSendMessage`, so E2E mention parsing never runs for upload captions. Mentions in encrypted rooms won’t be detected/notify when the message includes files.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/rooms.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/rooms.ts:294">
P2: `fileName`/`fileContent` are only removed when truthy, so falsy values can leak into `msgData` and fail `sendFileMessage` validation.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/meteor/app/api/server/v1/rooms.ts`:
- Around line 294-296: You update file.name from this.bodyParams.fileName but do
not update the stored/upload path or download name used later by
sendFileMessage(), which causes metadata/path divergence; before calling
sendFileMessage() (and after setting file.name and deleting
this.bodyParams.fileName) recompute and set the attachment’s upload/download
path using the same derivation used for the rooms.media/:rid upload (i.e., the
logic that created the original path from the original file name) and assign it
to the same field the message-sender uses (e.g., the
file.path/downloadName/attachment path) so the stored path matches the new
file.name.

In `@apps/meteor/client/lib/chats/flows/processMessageUploads.ts`:
- Around line 112-119: The code currently attaches composedMessage (currentMsg)
only to the first file (currentMsg = upload === filesToUpload[0]) which causes
one-message-per-file; change the logic to attach the composedMessage only once
for the whole batch by setting currentMsg for the last upload (e.g., upload ===
filesToUpload[filesToUpload.length - 1]) so the confirmation sent via
confirmFilesQueue (and the equivalent branch around lines 141-144) includes the
message only on that single confirm entry; update both occurrences (currentMsg
assignment and the confirmFilesQueue push) so only one /rooms.mediaConfirm entry
carries composedMessage containing tmid/msg/fileName while other file
confirmations omit composedMessage.
- Around line 182-206: The modal's cancel/close and the all-uploads-failed
acknowledgment currently call resolve(true) which signals success and causes the
caller to clear the composer, losing the draft; update the callbacks in
processMessageUploads (the imperativeModal handlers: the allUploadsFailed
branch, the non-failed onCancel, and onClose) to resolve(false) instead of
resolve(true) so that cancel/close/acknowledge do not indicate the message was
sent, and keep the confirm/onConfirm path unchanged (onConfirm should still call
resolve(continueSendingMessage(...))) so only an actual send clears the
composer.

In `@apps/meteor/client/lib/chats/flows/uploadFiles.ts`:
- Around line 69-70: The current code calls
chat.composer?.dismissAllQuotedMessages() immediately after awaiting uploads,
which clears the quote chain when the user merely attaches files; remove or
defer that call so attaching files doesn't wipe quotes. Specifically, in
uploadFiles.ts stop calling chat.composer?.dismissAllQuotedMessages() after
Promise.allSettled(files.map(file => uploadFile(file))) and instead invoke
chat.composer?.dismissAllQuotedMessages() from the message-send flow (the method
that finalizes/sends the message) or on successful send confirmation so quotes
are only cleared when the message is actually sent.
- Around line 28-33: The current branch calls uploadsStore.send(file) when
e2eRoom is not ready or settings.peek('E2E_Enable_Encrypt_Files') is false,
which downgrades encrypted-room uploads to plaintext; instead, do NOT call
uploadsStore.send(file) in this branch — abandon the entire upload queue for
this batch, surface a visible toast error (e.g. toasts/error or similar UI
helper) indicating encryption is required/not ready, and ensure the upload queue
is cleared/cancelled so no files are uploaded partially; change the logic around
e2eRoom?.isReady() and settings.peek('E2E_Enable_Encrypt_Files') to trigger the
abort+toast flow rather than falling back to plaintext.

In
`@apps/meteor/client/views/room/body/UploadProgress/UploadProgressIndicator.tsx`:
- Around line 16-29: The computed percentage uses validUploads (which includes
completed uploads) while count uses activeUploads, causing mismatch; change the
avgPercentage calculation inside the useMemo to derive from activeUploads (the
same set used for count) instead of validUploads: compute totalPercentage by
summing upload.percentage over activeUploads and then average/round it to
produce percentage, while keeping the early-return and count =
activeUploads.length logic in the useMemo (referencing useMemo, validUploads,
activeUploads, avgPercentage, percentage, count).

In `@apps/meteor/client/views/room/composer/messageBox/MessageBox.tsx`:
- Around line 389-390: canSendUploads currently only affects the toolbar button
but the textarea Enter key handler still allows submitting while uploads are in
progress and processMessageUploads drops attachments without id/url; update the
textarea submit handler (the onKeyDown / submit handler that reads
canSendUploads) to check the same guard (use canSendUploads or isUploading) and
prevent Enter-submission when uploads are pending, and modify
processMessageUploads to not clear the upload store or mutate attachments when
any attachment is missing id/url (either defer clearing until uploads complete
or preserve pending attachments and surface an error), ensuring unfinished
attachments are neither dropped nor sent.

In
`@apps/meteor/client/views/room/composer/messageBox/MessageBoxActionsToolbar/MessageBoxActionsToolbar.tsx`:
- Line 64: useWebdavActions is currently called unconditionally allowing WebDAV
uploads to bypass the message edit-mode guard; change the hook to accept the
edit state and return a no-op/disabled actions object when editing. Concretely,
update useWebdavActions to take a parameter (e.g. isEditing: boolean) and, when
isEditing is true, return an object where fileUploadAction and any other upload
handlers are disabled or no-op; then call it from MessageBoxActionsToolbar as
const webdavActions = useWebdavActions(uploadsStore, isEditing) so WebDAV
pathways respect the same isEditing restriction enforced for fileUploadAction.
- Line 63: The fileUploadAction is being disabled while the user is typing
because the condition passed to useFileUploadAction includes "typing"; update
the call in MessageBoxActionsToolbar to remove "typing" from the disabled
expression so the attachment button remains enabled when the draft has text
(i.e., change useFileUploadAction(!canSend || typing || isRecording ||
isEditing, uploadsStore) to useFileUploadAction(!canSend || isRecording ||
isEditing, uploadsStore)). Ensure you update the call site referencing
fileUploadAction/useFileUploadAction only and run related UI checks.

In `@apps/meteor/client/views/room/composer/messageBox/MessageComposerFile.tsx`:
- Around line 52-57: The cancel button is currently only rendered when isHover
is true, making it inaccessible to keyboard and touch users; update the logic in
the actionIcon rendering (and the similar branch around the other occurrence) so
that when isLoading you still render an accessible IconButton wired to
handleDismiss (and keep MessageComposerFileLoader for visual loading if
desired), i.e., do not gate the IconButton behind isHover — render the
IconButton during isLoading so it is focusable and clickable by keyboard/touch,
ensure it keeps the existing aria-label and onClick handler.

In
`@apps/meteor/client/views/room/composer/messageBox/MessageComposerFileLoader.tsx`:
- Line 22: The SVG's spinner class is being overwritten because {...props} is
spread after className={customCSS} in the Box element; update
MessageComposerFileLoader to merge class names instead of letting caller props
replace them—either spread {...props} before the fixed props or compute a
combined className (e.g., combine customCSS with props.className) and pass that
merged value into the Box's className so the spinner animation from customCSS is
preserved while allowing caller className to be appended.

In `@apps/meteor/tests/e2e/e2e-encryption/e2ee-encryption-decryption.spec.ts`:
- Around line 101-106: The test wraps non-idempotent UI actions in a retrying
expect(...).toPass(), causing duplicate submissions; change the flow in the
e2ee-encryption-decryption.spec.ts to remove the toPass wrapper around the
sequence using encryptedRoomPage.composer.getFileByName(...).click(),
fileUploadModal.setName(...), and fileUploadModal.update(); instead, wait for
the pending upload chip (the pending upload element exposed by
encryptedRoomPage/composer) to appear, perform the rename and update exactly
once, then assert the final state with
expect(encryptedRoomPage.composer.getFileByName(fileName)).toBeVisible(); apply
the same fix to the similar block referenced at lines ~124-129.

In `@apps/meteor/tests/e2e/e2e-encryption/e2ee-file-encryption.spec.ts`:
- Around line 134-141: The test captures composerFiles before performing the
upload, so the subsequent readonly assertions check stale elements; move the
call to compose file lookup (composerFilesLocator and composerFiles) to after
invoking poHomeChannel.content.dragAndDropTxtFile() and then query the new
file(s) (e.g., by composerFilesLocator.all() or locating TEST_FILE_TXT) and
assert they have the readonly attribute and that
poHomeChannel.content.lastUserMessage.locator('.rcx-icon--name-key') is visible;
in short, perform dragAndDropTxtFile() first, then re-query
composerFiles/composerFilesLocator and run the expectations against those fresh
elements.

In `@apps/meteor/tests/e2e/file-upload.spec.ts`:
- Around line 121-130: The negative assertion is checking the wrong filename;
after sending ten number1.png files and then calling
poHomeChannel.content.dragAndDropTxtFile() the test should assert that the TXT
file is not present. Update the test (the 'should respect the maximum number of
files allowed per message: 10' case) to look for the TXT filename produced by
poHomeChannel.content.dragAndDropTxtFile() (e.g., 'any_file.txt') when calling
poHomeChannel.composer.getFileByName(...) and assert it is not visible while
still asserting poHomeChannel.composer.getFilesInComposer() has count 10.

In `@apps/meteor/tests/e2e/fixtures/responses/mediaResponse.ts`:
- Around line 3-6: The current isMediaResponse matcher is too broad and matches
mediaConfirm requests; update isMediaResponse to only match the upload endpoint
by making the URL regex anchored to the end of the path (and allow optional
query string) e.g. test against a pattern like
/^.*\/api\/v1\/rooms\.media(?:\?.*)?$/ while still checking
response.request().method() === 'POST'; this ensures
createMediaResponsePromise(page) waits for the actual upload response rather
than a mediaConfirm call.

In `@apps/meteor/tests/e2e/image-upload.spec.ts`:
- Line 40: The test currently only asserts the composer entry has a readonly
attribute via poHomeChannel.composer.getFileByName('bad-orientation'), so update
the assertion to first assert the upload error UI is visible using the existing
page-object locator (statusUploadError) — e.g.,
expect(poHomeChannel.statusUploadError).toBeVisible() — and keep the readonly
check as a secondary assertion if desired; locate these in the same test that
references poHomeChannel.composer.getFileByName('bad-orientation') and
replace/augment the single readonly-only expectation with the visible error
assertion.
- Around line 52-55: Replace the loose filename text assertion with an assertion
that the uploaded attachment element is present by using HomeContent's
getLastMessageByFileName helper: after calling
poHomeChannel.content.sendFileMessage(imgName) and
poHomeChannel.composer.btnSend.click(), call
poHomeChannel.content.getLastMessageByFileName(imgName) and assert
visibility/contents with a web-first matcher (e.g., toBeVisible or toHaveText)
instead of checking
poHomeChannel.content.lastUserMessage.toContainText(imgName); this ensures the
test verifies the actual file attachment rendering.

In `@apps/meteor/tests/e2e/page-objects/fragments/home-content.ts`:
- Line 399: The three methods dragAndDropTxtFileToThread, sendFileMessage, and
sendFileMessageToThread destructure an options object without a TypeScript type;
update each signature to annotate the destructured parameter (e.g. change "({
waitForResponse = true } = {})" to include a type like "{ waitForResponse?:
boolean }" so it becomes "({ waitForResponse = true }: { waitForResponse?:
boolean } = {})") to satisfy strict TS mode; apply the same pattern for any
other destructured option parameters (use optional boolean types matching the
default values).

In `@apps/meteor/tests/e2e/prune-messages.spec.ts`:
- Around line 44-46: The click on poHomeChannel.composer.btnSend races with the
attachment preview because sendFileMessage only waits for the HTTP response; add
a UI-level wait like await
expect(content.getFileByName('any_file.txt')).toBeVisible() (or equivalent
page-object method) immediately after calling
content.sendFileMessage('any_file.txt') and before invoking
poHomeChannel.composer.btnSend.click(); alternatively, implement a helper on the
page object (e.g., composer.attachAndSendFile(fileName)) that performs
sendFileMessage, waits for getFileByName(fileName) toBeVisible(), then clicks
btnSend, and replace the three occurrences that currently call sendFileMessage +
btnSend.click() with this helper.

---

Nitpick comments:
In `@apps/meteor/client/lib/chats/uploads.ts`:
- Around line 145-166: The onload handler in the XHR upload flow (xhr.onload)
treats all non-200/400 responses as a generic i18n error; update it to include
the HTTP status and response body in the error passed to updateUpload to aid
debugging. Concretely, inside xhr.onload (the same block that handles xhr.status
=== 400 and === 200), construct a descriptive error message (e.g., include
xhr.status and xhr.responseText or attempt to JSON.parse it) and call
this.updateUpload(id, { percentage: 0, error: new Error(<constructed message>)
}); optionally also log the full xhr object or the constructed message before
calling updateUpload; reuse getErrorMessage for thrown exceptions as currently
done. Ensure you only change the non-200/400 branch and keep existing behavior
for 200 and 400 cases.

In `@apps/meteor/client/views/room/body/RoomBody.tsx`:
- Around line 203-206: Remove the commented JSX wrapper markers around the
upload indicator: delete the commented lines "// <UploadProgressContainer>" and
"// </UploadProgressContainer>" so the conditional render uses a single line
with the existing isUploading check and UploadProgressIndicator; if you intended
to keep a container, replace the comments with the actual
<UploadProgressContainer> wrapper around <UploadProgressIndicator
uploads={uploads} /> instead of commented scaffolding.

In
`@apps/meteor/client/views/room/composer/messageBox/MessageComposerFileComponent.tsx`:
- Line 14: Remove the inline TODO comment in MessageComposerFileComponent and
instead create and reference an external task in your issue tracker (e.g., an
issue/board card to move this component into ui-composer); update the component
(MessageComposerFileComponent) to have no implementation comments and, if
helpful, add a short single-line TODO reference to the created issue ID (or
include the issue URL) in the commit message so the work is tracked externally
rather than leaving a code comment.

In
`@apps/meteor/client/views/room/composer/messageBox/MessageComposerFileError.tsx`:
- Line 18: The prop expression error={Boolean(error)} is redundant because the
local symbol error is typed as non-optional Error; replace the coercion with a
literal true (error={true}) when the component always receives an Error, or
instead make the component prop optional in the MessageComposerFileError props
type (e.g., change Error -> Error | undefined or mark error?: Error) if you
intend to support no-error states and keep the Boolean(...) check; update the
component's props interface (and any call sites using MessageComposerFileError)
accordingly.

In
`@apps/meteor/client/views/room/composer/messageBox/MessageComposerFileLoader.tsx`:
- Line 5: Remove the inline TODO comment at the top of
MessageComposerFileLoader.tsx (the "// TODO: This component should be moved to
fuselage" note) and instead create a corresponding ticket or follow-up task in
the issue tracker referencing MessageComposerFileLoader so the migration can be
tracked; leave the implementation file free of TODO comments per the coding
guidelines.

In
`@apps/meteor/client/views/room/contextualBar/Threads/components/ThreadChat.tsx`:
- Around line 56-62: The optional chaining in handleNavigateToPreviousMessage
and handleNavigateToNextMessage is redundant because chat is guaranteed by the
runtime guard earlier; update both callbacks to call
chat.messageEditing.toPreviousMessage() and chat.messageEditing.toNextMessage()
respectively (remove the "?"), and use the exact referenced value in the
dependency arrays (e.g. [chat.messageEditing]) so React hooks depend on the real
object.

In
`@apps/meteor/client/views/room/webdav/WebdavFilePickerModal/WebdavFilePickerModal.tsx`:
- Around line 131-147: The uploadFile function declares an unused description
parameter; remove the description argument from uploadFile's signature and any
related prop/type references (e.g., the uploadFile function in
WebdavFilePickerModal.tsx and the onUpload prop type) so the function only
accepts (file: File): Promise<void>, and update any related type/interface
definitions and callers (such as the onUpload prop type) to reflect that
descriptions are no longer passed in this flow.

In `@apps/meteor/tests/e2e/e2e-encryption/e2ee-file-encryption.spec.ts`:
- Line 71: Extract the repeated CSS selector into the HomeChannel page object:
add a locator property (e.g., poHomeChannel.content.encryptionIcon) that wraps
the current selector ('.rcx-icon--name-key') and replace all inline uses (lines
referencing poHomeChannel.content.locator('.rcx-icon--name-key')) with
poHomeChannel.content.encryptionIcon; if the DOM exposes a semantic attribute
like aria-label or title, prefer implementing the locator using
getByLabel()/getByTitle() in the new property instead of the raw CSS selector.

In `@apps/meteor/tests/e2e/message-composer.spec.ts`:
- Line 197: Replace the hardcoded sleep call page.waitForTimeout(1000) with an
explicit wait for a specific UI/state change (e.g., wait for a recording
indicator or duration element to appear/update) by using Playwright's
page.waitFor or locator.waitFor with a condition; locate the test that calls
page.waitForTimeout(1000) and change it to await page.waitForFunction(() => /*
check recorder state or duration value */) or await
locator('selector-for-recording-indicator').waitFor({ state: 'visible' }) so the
test waits for the recorder's actual state/duration instead of a fixed timeout.

In `@apps/meteor/tests/e2e/page-objects/fragments/home-content.ts`:
- Line 393: The inline overlay selector
'[role=dialog][data-qa="DropTargetOverlay"]' and the room/thread file-input
selectors are duplicated across helpers; move these into page-object getters on
HomeContent (e.g., add a dropTargetOverlay getter) and into
RoomComposer/ThreadComposer (e.g., fileInput getter) and update all usages
(including the dispatchEvent('drop', { dataTransfer }) call and occurrences
around lines 412 and 420–429) to use those getters so selectors are centralized
and the page-object boundary is preserved.

In `@apps/meteor/tests/e2e/page-objects/fragments/modals/file-upload-modal.ts`:
- Around line 33-35: Replace the public raw locator btnOk with a private locator
(e.g., _btnOk or btnOkLocator) and add a public action method confirm() that
clicks the private locator and waits for the modal to dismiss using the existing
waitForDismissal() helper; mirror the same pattern used by cancel() and
confirmSend() so callers use confirm() instead of accessing the locator directly
(also update the other similar locators/actions in the same file around the
45-57 area to follow this private-locator + action-method pattern).

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/meteor/client/views/room/body/RoomBody.tsx">

<violation number="1" location="apps/meteor/client/views/room/body/RoomBody.tsx:203">
P2: Keep the upload indicator visible until the uploads store is cleared; `isUploading` turns false before attachment confirmation finishes.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/processMessageEditing.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/processMessageEditing.ts:26">
P2: Don't clear the composer until `updateMessage` succeeds, or failed edits will discard the user's current text.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/processSlashCommand.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/processSlashCommand.ts:94">
P2: Clear the composer only after the slash command succeeds; clearing it before the request loses the user's command text on errors.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/sendMessage.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/sendMessage.ts:32">
P2: Clearing the composer before `sdk.call('sendMessage', ...)` causes the user's message text to be lost if the send request fails. Move `clear()` after the await so text is only discarded on success.</violation>
</file>

<file name="apps/meteor/client/views/room/composer/messageBox/MessageComposerFileItem.tsx">

<violation number="1" location="apps/meteor/client/views/room/composer/messageBox/MessageComposerFileItem.tsx:28">
P3: Use the extension helper here; `getMimeType` makes the subtitle show MIME types like `application/pdf` instead of file extensions.</violation>
</file>

<file name="apps/meteor/app/ui/client/lib/ChatMessages.ts">

<violation number="1" location="apps/meteor/app/ui/client/lib/ChatMessages.ts:127">
P1: Clear the active upload store only after the edit is allowed to start. This line currently deletes queued files on failed edit attempts, and in thread context it can clear the wrong store when editing the thread root message.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/processSetReaction.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/processSetReaction.ts:24">
P2: Clear the composer only after `setReaction` succeeds; otherwise a failed request discards the user's input.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/uploadFiles.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/uploadFiles.ts:74">
P2: `performContinuously('uploading')` is started unconditionally but is only stopped inside `processMessageUploads`, which runs when the user sends the message. If every file fails during encryption (or `files` is empty), no entries are added to the uploads store, the user never triggers a send, and the 'uploading' status indicator is never cleared.

Wrap the upload batch in a try/finally that stops the action when no files were successfully staged.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/processMessageUploads.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/processMessageUploads.ts:60">
P2: `URL.createObjectURL()` is called but never revoked, leaking the blob URL. Store the URL, use it, then call `URL.revokeObjectURL()` after the image loads.</violation>

<violation number="2" location="apps/meteor/client/lib/chats/flows/processMessageUploads.ts:189">
P1: Promise never resolves when the user closes the modal, clicks Cancel, or clicks OK on an all-failed dialog. Each of these paths calls `imperativeModal.close()` but never calls `resolve()`, leaving the caller permanently awaiting. Add `resolve(true)` (or `resolve(false)`) in every exit path.</violation>
</file>

<file name="apps/meteor/client/views/room/composer/messageBox/MessageBox.tsx">

<violation number="1" location="apps/meteor/client/views/room/composer/messageBox/MessageBox.tsx:174">
P1: This changed send path no longer clears the composer before starting the async send, so rapid Enter/click repeats can submit the same message twice.</violation>

<violation number="2" location="apps/meteor/client/views/room/composer/messageBox/MessageBox.tsx:503">
P2: `hasUploads` also counts failed uploads, so this enables Send even when the queue has no sendable files.</violation>
</file>

<file name="apps/meteor/client/lib/chats/flows/processTooLongMessage.ts">

<violation number="1" location="apps/meteor/client/lib/chats/flows/processTooLongMessage.ts:35">
P1: Clearing the composer before `uploadFiles()` can drop the user's long message when the attachment cannot be queued.</violation>
</file>

<file name="apps/meteor/client/views/room/modals/FileUploadModal/FileUploadModal.tsx">

<violation number="1" location="apps/meteor/client/views/room/modals/FileUploadModal/FileUploadModal.tsx:29">
P2: This refactor drops attachment descriptions/captions from the composer upload flow. Users can still rename a file, but there is no longer any way to send the per-file `description` that `rooms.mediaConfirm` and attachment rendering still support.</violation>
</file>

<file name="apps/meteor/client/views/room/body/hooks/useFileUpload.ts">

<violation number="1" location="apps/meteor/client/views/room/body/hooks/useFileUpload.ts:22">
P2: Stop the `uploading` action based on active uploads, not total attachments. Canceling the last in-flight upload currently leaves a stale uploading indicator when completed attachments remain in the composer.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/rooms.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/rooms.ts:300">
P2: Validate `fileContent` before persisting it. This endpoint currently accepts any value and writes it into `file.content`, which can create malformed encrypted upload metadata.</violation>
</file>

<file name="apps/meteor/client/lib/chats/uploads.ts">

<violation number="1" location="apps/meteor/client/lib/chats/uploads.ts:147">
P1: On XHR network errors, `reject(event)` passes a `ProgressEvent` to the catch block. `getErrorMessage` cannot extract a message from a `ProgressEvent` (it has no `message`, `reason`, or `error` string property) and no `defaultMessage` is provided, so it throws `TypeError('no default error message specified')` — producing an unhandled promise rejection.

Either reject with an `Error` wrapping the response text, or provide a default message to `getErrorMessage`.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/meteor/client/lib/chats/flows/processMessageEditing.ts`:
- Around line 26-27: The composer is being cleared before the save completes
which can lose input if updateMessage fails; change flow in
processMessageEditing so you call chat.data.updateMessage({ ...message, _id: mid
}, previewUrls) first (await it), and only call chat.composer?.clear() after
that promise resolves successfully; wrap the await in a try/catch to avoid
clearing on error and surface/log the failure (or rethrow) so failed edits don’t
erase the composer contents.

In `@apps/meteor/client/lib/chats/flows/processMessageUploads.ts`:
- Around line 149-157: The current processMessageUploads function always returns
true even after a failed media confirm (catch block), which misreports failure
as success; update function flow so that a successful true is only returned when
the confirm/upload completes without throwing (e.g., move or add the final
"return true" inside the try path or return a boolean based on success flag),
ensure existing cleanup in the finally block (store.setProcessingUploads(false)
and chat.action.stop('uploading')) remains, and keep the error handling via
dispatchToastMessage(error) in the catch so failures return false (or
no-success) instead of true.

In `@apps/meteor/client/lib/chats/flows/processSlashCommand.ts`:
- Around line 94-95: The composer is being cleared before invoking
sdk.call('slashCommand', ...) which loses the user's typed command if the call
fails; change the flow in processSlashCommand so that chat.composer?.clear() is
performed only after the slashCommand call succeeds (i.e., after awaiting
sdk.call and verifying success), and if the call rejects or returns an error, do
not clear the composer (or restore the original message text into chat.composer)
so the user's input is preserved; update the handling around
sdk.call('slashCommand', { cmd: commandName, params, msg: message, triggerId })
and move or conditionalize chat.composer?.clear() accordingly.

In `@apps/meteor/client/lib/chats/flows/uploadFiles.ts`:
- Around line 13-27: The validation early-returns (max files and encrypted-room
checks around mergedFilesLength/MAX_MULTIPLE_UPLOADED_FILES and room.encrypted
with settings.peek(...)) do not clear the native file input, so re-selecting the
same files won't fire change; before each validation return, call the same reset
that currently runs at the successful-return path (i.e., clear the native file
input element or invoke the existing resetFileInput/resetInput function) so the
input.value is reset when dispatchToastMessage(...) is returned due to
validation failure.

In `@apps/meteor/client/views/room/body/hooks/useFileUpload.ts`:
- Around line 21-25: The stopUploadingAction currently checks uploads.length (in
useFileUpload's stopUploadingAction) which counts all attachments rather than
active in-flight uploads; change it to use the active upload count or the
upload.isUploading transition (e.g., inspect uploads.filter(u =>
u.isUploading).length or rely on the isUploading flag on each upload) so
stop('uploading') is only called when there are zero active uploads; update the
remove/cancel handlers and the upload completion path (the handlers around where
stopUploadingAction is invoked and where a successful upload resolves,
referenced in the same file) to call the revised stopUploadingAction or directly
check active uploads/isUploading before calling chat.action.stop('uploading').

In
`@apps/meteor/client/views/room/composer/messageBox/MessageBoxActionsToolbar/hooks/useWebdavActions.tsx`:
- Around line 12-13: The "Add Server" menu item in useWebdavActions is not
honoring the incoming disabled flag (disabled param) so the toolbar remains
partially interactive; update the webdav-add menu item's props inside
useWebdavActions to include the same disabled gating used for account actions
(e.g., set disabled: true when the function's disabled || !enabled condition
applies), ensuring the 'webdav-add' GenericMenuItemProps is blocked when
disabled is true or Webdav_Integration_Enabled is false.

In `@apps/meteor/tests/e2e/file-upload.spec.ts`:
- Around line 121-125: The test uses Promise.all to call
poHomeChannel.content.sendFileMessage concurrently with the same file input
causing race conditions; change the loop to upload files sequentially by
iterating over the files array and awaiting
poHomeChannel.content.sendFileMessage(file) for each item (then call
poHomeChannel.content.dragAndDropTxtFile() as before) so the max-files
enforcement is tested deterministically.
- Around line 59-67: The test 'should attach multiple files and send one per
message' currently has no effective assertions before send and only checks a
single download link after send; update it to assert both attachments are
present and result in two separate messages: use
poHomeChannel.composer.getFileByName(TEST_FILE_TXT) and
getFileByName(TEST_FILE_LST) with explicit truthy/exists assertions before
clicking poHomeChannel.composer.btnSend, then after send assert that
poHomeChannel.content has two user message download links (e.g.,
expect(poHomeChannel.content.lastUserMessageDownloadLink).toHaveCount(2) or
assert each message contains the respective filename), ensuring each file
produced its own message as intended.
- Around line 47-53: The current assertion
expect(poHomeChannel.composer.getFileByName(updatedFileName)) is a no-op;
replace it with a real Playwright matcher and await it (for example: await
expect(poHomeChannel.composer.getFileByName(updatedFileName)).toBeVisible() or
await
expect(poHomeChannel.composer.getFileByName(updatedFileName)).toHaveCount(1));
update the assertion in the test.step block where getFileByName(updatedFileName)
is used (before calling poHomeChannel.composer.btnSend.click()) and ensure
Playwright's expect is imported so the check actually verifies the renamed file
chip is present/visible.

In
`@packages/ui-composer/src/MessageComposer/MessageComposerFile/MessageComposerFile.tsx`:
- Around line 56-72: The consumer-provided className currently overwrites the
component's internal previewWrapperStyle in the MessageComposerFile component;
modify the JSX where previewWrapperStyle and {...props} are applied (the element
with className={previewWrapperStyle}) to merge the two class names instead of
allowing props.className to override—use the project's class merging utility
(e.g., clsx/classNames) or a template string to combine previewWrapperStyle and
props.className (ensuring the internal previewWrapperStyle remains first) and
remove className from the rest spread if necessary so the merged class is passed
to the element.

In
`@packages/ui-composer/src/MessageComposer/MessageComposerFile/MessageComposerFileGroup.tsx`:
- Around line 15-16: In MessageComposerFileGroup (the React component in
MessageComposerFileGroup.tsx) the inline style { whiteSpace: 'nowrap',
...props.style } is being overwritten by the subsequent {...props} spread; fix
by avoiding spreading props after the style—either destructure props (e.g.,
const { style, ...rest } = props) and render with style={{ whiteSpace: 'nowrap',
...(style || {}) }} and then {...rest}, or move {...props} before the style prop
so the composed style wins; update the JSX in MessageComposerFileGroup
accordingly.

---

Outside diff comments:
In `@apps/meteor/client/lib/chats/flows/processTooLongMessage.ts`:
- Around line 25-39: The onConfirm callback currently clears the draft
(chat.composer?.clear()) and closes the modal before awaiting
chat.flows.uploadFiles(), so if uploadFiles rejects the draft is lost and the
Promise never resolves; change the flow so you first attempt to queue/upload the
file by awaiting chat.flows.uploadFiles(...) and only clear the composer and
close the modal after that call succeeds (or at least after the upload is
confirmed queued), and ensure the modal promise is always settled by calling
resolve() in both success and error paths (use try/catch/finally around the
await of uploadFiles to call imperativeModal.close() and resolve(), and on error
leave the composer content intact or restore it so the draft is not lost).

---

Duplicate comments:
In `@apps/meteor/client/lib/chats/flows/processMessageUploads.ts`:
- Around line 186-208: The modal close handlers currently call
imperativeModal.close() but never resolve the Promise returned by
processMessageUploads, leaving callers hanging; update the three handlers tied
to the allUploadsFailed acknowledgement, the cancel path and the onClose path so
they call resolve with the appropriate value (e.g., resolve(false) for
cancelled/closed paths and resolve(continueSendingMessage(chat, store, message))
where the user confirms sending), and ensure the
failedUploads.forEach(store.removeUpload) logic remains before resolving in the
non-all-failed confirm path; reference processMessageUploads,
imperativeModal.close(), continueSendingMessage, failedUploads,
store.removeUpload, allUploadsFailed and resolve to locate and modify the
handlers.

In `@apps/meteor/client/lib/chats/flows/uploadFiles.ts`:
- Around line 37-39: The current check lumps missing e2eRoom with the
feature-flag off and silently uploads plaintext; change the logic so that only
when settings.peek('E2E_Enable_Encrypt_Files') is false you call
uploadsStore.send(file), but if E2E file encryption is enabled and e2eRoom is
missing (e2eRoom === null/undefined) fail fast (throw or reject the batch)
instead of calling uploadsStore.send; update the branch around e2eRoom and
settings.peek('E2E_Enable_Encrypt_Files') in uploadFiles.ts so callers of the
upload flow (the function handling this loop) receive the error and the batch
fails rather than downgrading to plaintext.

In
`@apps/meteor/client/views/room/body/UploadProgress/UploadProgressIndicator.tsx`:
- Around line 16-29: The percentage is averaged over validUploads but the count
shows activeUploads, causing mismatch when some uploads are complete; update the
useMemo in UploadProgressIndicator (the validUploads / activeUploads logic) so
that percentage is computed only from the same set you report as count (i.e.,
average over activeUploads instead of validUploads) and return { percentage,
count: activeUploads.length } so the reported percentage and count reflect the
same uploads.

In `@apps/meteor/tests/e2e/e2e-encryption/e2ee-encryption-decryption.spec.ts`:
- Around line 122-127: The test currently wraps non-idempotent actions
(encryptedRoomPage.composer.getFileByName(...).click, fileUploadModal.setName,
fileUploadModal.update) inside the toPass retry wrapper which can re-run those
side effects and cause flakiness; change the flow so you perform the click,
setName, and update exactly once (call
encryptedRoomPage.composer.getFileByName(...).click();
fileUploadModal.setName(...); await fileUploadModal.update();) and then wrap
only the assertion that the renamed file is visible (e.g.
expect(encryptedRoomPage.composer.getFileByName(fileName)).toBeVisible()) with
toPass or use an explicit Playwright wait/assert, ensuring to reference the
existing encryptedRoomPage.composer.getFileByName, fileUploadModal.setName,
fileUploadModal.update, and toPass symbols when making the change.

In `@apps/meteor/tests/e2e/image-upload.spec.ts`:
- Line 40: The test currently only asserts readonly on
poHomeChannel.composer.getFileByName('bad-orientation.jpeg'), which can miss
regressions in the user-visible error state; update the assertion to also check
the visible upload error (use Playwright web-first assertions) by locating the
same file element via
poHomeChannel.composer.getFileByName('bad-orientation.jpeg') and asserting its
error indicator is visible or contains the expected text (e.g., use
toBeVisible() or toHaveText('upload error' or the app's exact message)) so the
test validates the user-facing error as well as readonly.
- Around line 52-55: Replace the brittle text assertion that checks for imgName
with a web-first assertion that verifies an uploaded-file element was rendered:
after calling poHomeChannel.content.sendFileMessage and clicking
poHomeChannel.composer.btnSend, locate the file/attachment element inside
poHomeChannel.content.lastUserMessage (e.g., the image thumbnail, attachment
container or filename element) and assert it is visible and/or has the filename
using toBeVisible/toHaveText instead of toContainText; update the test to target
that attachment element rather than relying on generic message text.

---

Nitpick comments:
In `@apps/meteor/client/lib/chats/flows/processMessageUploads.ts`:
- Around line 110-113: Remove the inline implementation comment and make the
intent explicit by introducing a boolean (e.g., shouldKeepComposedMessage or
isFirstMessage) inside processMessageUploads; compute it from the message
index/iteration context and use that boolean in the conditional that currently
decides whether to keep composedMessage or set text to '' (instead of relying on
a naked condition + comment). Update the assignment/branch that references
composedMessage/text to use this self-descriptive variable and delete the
comment.

In `@apps/meteor/client/lib/chats/flows/processSetReaction.ts`:
- Around line 24-25: The composer is cleared before the async call to
callWithErrorHandling('setReaction', reaction, lastMessage._id), which can drop
the typed command if the call fails; move chat.composer?.clear() to run after
the await so clearing happens only on successful completion of setReaction
(i.e., callWithErrorHandling resolves) and reference chat.composer?.clear(),
callWithErrorHandling('setReaction', ...), and lastMessage._id when making the
change.

In `@apps/meteor/client/lib/chats/flows/sendMessage.ts`:
- Around line 96-98: Remove the inline implementation comment inside
apps/meteor/client/lib/chats/flows/sendMessage.ts that precedes the "if (mid)"
branch; specifically delete the two comment lines starting with "// When editing
an encrypted message..." and "// This ensures..." so the code reads directly
with the if (mid) block, preserving existing logic in the sendMessage flow.

In `@apps/meteor/client/lib/chats/uploads.ts`:
- Around line 119-121: Replace the magic -1 sentinel with a named constant to
make the intent self-documenting: introduce a constant like UNLIMITED_FILE_SIZE
(or NO_SIZE_LIMIT) and use it in the size-check conditional that references
maxFileSize (the block that currently reads "if (maxFileSize > -1 && (file.size
|| 0) > maxFileSize)"): update the condition to compare against the new constant
and keep the existing reject(new Error(...)) behavior; define the constant near
related upload configuration or at the top of this module and export it if it’s
used elsewhere so the code no longer needs the inline comment to explain the
sentinel.

In `@apps/meteor/tests/e2e/page-objects/fragments/home-content.ts`:
- Around line 380-416: Both dragAndDropLstFile and dragAndDropTxtFileToThread
repeat the same drop overlay locator; add a shared getter (e.g., a method or
property on this page-object class named dropTargetOverlay or
getDropTargetOverlay) that returns
this.page.locator('[role=dialog][data-qa="DropTargetOverlay"]'), then replace
the inline locator calls in dragAndDropLstFile and dragAndDropTxtFileToThread
with that getter (use dropTargetOverlay.dispatchEvent('drop', { dataTransfer })
so both helpers reuse the same locator).

In `@packages/i18n/src/locales/en.i18n.json`:
- Line 5913: There are two near-duplicate translation keys for the same "too
many files" limit (e.g., "You_cant_upload_more_than__count__files" and the other
similar key found elsewhere); consolidate them into a single canonical key (pick
one, e.g., "You_cant_upload_more_than__count__files"), update any code
references or other locale keys to use that single key, and remove the duplicate
entry; ensure the chosen key uses the consistent placeholder "{{count}}" and
update any tests or components that referenced the old key to prevent
regressions.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@apps/meteor/tests/e2e/file-upload.spec.ts`:
- Around line 59-67: After sending the two files, add assertions that each file
produced its own message by checking for messages/download links containing each
filename (use the existing TEST_FILE_TXT and TEST_FILE_LST identifiers) instead
of only asserting lastUserMessageDownloadLink count; update the test to, after
poHomeChannel.composer.btnSend.click(), assert presence of a message or download
link for TEST_FILE_TXT and separately for TEST_FILE_LST via the
poHomeChannel.content helpers (e.g., look up messages/download links by
filename) so both files are verified as distinct sent messages.

---

Nitpick comments:
In `@apps/meteor/tests/e2e/file-upload.spec.ts`:
- Around line 127-128: Replace the string literal 'any_file.txt' with the
existing test constant TEST_FILE_TXT in the assertion that calls
poHomeChannel.composer.getFileByName so the test uses the canonical filename;
update the call in the file-upload.spec.ts expectation (the second line shown)
to pass TEST_FILE_TXT to getFileByName instead of the hardcoded string.

In
`@packages/ui-composer/src/MessageComposer/MessageComposerFile/MessageComposerFileGroup.tsx`:
- Around line 6-7: The Box with role='group' in MessageComposerFileGroup lacks
an accessible name; update MessageComposerFileGroup to provide an aria-label (or
aria-labelledby) for that Box so screen readers can identify the attachments
group—either hardcode a meaningful label like "Attachments" or accept a
translatable prop (e.g., attachmentsLabel) on the MessageComposerFileGroup
component and pass it into the Box as aria-label, or use your i18n hook to
supply the label.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/ui-composer/src/MessageComposer/MessageComposerFile/MessageComposerFileLoader.tsx">

<violation number="1" location="packages/ui-composer/src/MessageComposer/MessageComposerFile/MessageComposerFileLoader.tsx:5">
P2: Use SVG props here instead of `AllHTMLAttributes`. Because this loader renders `is='svg'` and is publicly exported, the new type turns valid SVG attributes into TypeScript errors for consumers.</violation>
</file>