Native app - Unable to share video to the app as an attachment

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.1.93-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2219752/folder/13176721/test-cases/41236966
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Device used: Samsung Galaxy s10/ Android 12
App Component: Other

Action Performed:

1. Navigate to Hybrid App
2. Sign in to any account
3. On the device media library - Select a video and click share
4. Select share to Expensify
5. Select any contact or workspace

Expected Result:

You land in Details page where "To" field is populated as per the selection and preview of the file is displayed and can share a video to the selected recipient as attachment.

Actual Result:

There is no attachment preview exist
Share button is unresponsive

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @alexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[dmkt9]

Proposal

Please re-state the problem that we are trying to solve in this issue.

There is no attachment preview exist
Share button is unresponsive

What is the root cause of that problem?

1. The isValidatingReceipts param of useFilesValidation is set to true by default:
   

   App/src/hooks/useFilesValidation.tsx

   Line 34 in 8dcc9d3

   function useFilesValidation(proceedWithFilesAction: (files: FileObject[]) => void, isValidatingReceipts = true) {

2. This causes validateAttachment to validate the video file as a receipt:
   

   App/src/hooks/useFilesValidation.tsx

   Line 116 in 8dcc9d3

   const error = validateAttachment(normalizedFile, isCheckingMultipleFiles, isValidatingReceipts);

3. However, since video files are not allowed as receipts, the validation always fails:
   

   App/src/CONST/index.ts

   Line 258 in 8dcc9d3

   ALLOWED_RECEIPT_EXTENSIONS: ['heif', 'heic', 'jpg', 'jpeg', 'gif', 'png', 'pdf', 'htm', 'html', 'text', 'rtf', 'doc', 'tif', 'tiff', 'msword', 'zip', 'xml', 'message'],

   
   As a result, isValidFile always returns false for video files, and validFilesToUpload.length === 0.

What changes do you think we should make in order to solve the problem?

Originally, isValidatingReceipts in useFilesValidation was set to false by default, and this behavior was changed in this commit.
To resolve this issue, we should explicitly pass isValidatingReceipts = false here:

App/src/pages/Share/ShareDetailsPage.tsx

Line 59 in 8dcc9d3

const {validateFiles} = useFilesValidation(setValidFilesToUpload);

Note: It may be necessary to review all usages of useFilesValidation and update the isValidatingReceipts param accordingly.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

NA

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Result:

2025-08-13.23-22-25.mp4

[alexpensify]

We are reviewing whether the fix covers all file types or just .mp3s here - #64136 (comment)

[linhvovan29546]

@alexpensify The offending PR has been reverted (#68427) and has just been deployed to staging. We should ask retest to confirm that this issue has been resolved.

[rohit9625]

Yes, this issue is not reproducible anymore after that PR was reverted.

Screen_recording_20250817_235206.mp4

[alexpensify]

Thanks for the feedback. I've asked for a retest here - https://expensify.slack.com/archives/C9YU7BX5M/p1755563105743859

[kavimuru]

Bug is not reproducible

1000141977.mp4

[alexpensify]

Thanks! Based on this feedback, I'm going to close this GitHub.