Skip to content

[HOLD for payment 2022-11-16] [$250] [Image] Cant Share attachments between 40-49 mb - reported by @Tushu17 #8235

Closed

Description

@mvtglobally

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


Action Performed:

  1. Go to chat
  2. Select Actions -> Add attachment
  3. Add an around 45 mb video/file (file in tread)

Expected Result:

Error should be shown immediately since the limit of the file we can at the moment process is 25MB. Let's not have the user wait for the upload if we know it cannot succeed.

Actual Result:

Attachment kept loading until you refresh the page, attachment disappears after refreshing.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platform:

Where is this issue occurring?

  • Web
  • iOS
  • Android
  • Desktop App
  • Mobile Web

Version Number: 1.1.43-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

VID_374491118_125842_369.mp4

Expensify/Expensify Issue URL:
Issue reported by: @Tushu17
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1644521208448039

View all open jobs on GitHub

Activity

  1. melvin-bot commented on Mar 19, 2022

    @melvin-bot

    Triggered auto assignment to @mallenexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

  2. removed
    AutoAssignerTriageAuto assign issues for triage to an available triage team member
    on Mar 19, 2022
  3. mallenexpensify commented on Mar 21, 2022

    @mallenexpensify
    Contributor

    Well... that is a weird one, nice catch @Tushu17
    I was able to reproduce, got this is logs
    image

    The pdf file @Tushu17 was using is here in slack

    If/when we fix this, it'd be great to know why it's happening and to make sure we fix it for all file sizes.

  4. removed their assignment
    on Mar 21, 2022
  5. melvin-bot commented on Mar 21, 2022

    @melvin-bot

    Triggered auto assignment to @marcochavezf (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

  6. marcochavezf commented on Mar 22, 2022

    @marcochavezf
    Contributor

    Marking this issue as internal, because the logs show that there's a size issue on backend:

    2022-03-22T20:13:58.941746+00:00 expensidev2004 php-fpm: QHP2Bx /api.php marco+test1@expensify.com !ecash! ?report? [info] Benchmark started:PDFBoxAPI - SPost2
    2022-03-22T20:13:58.952725+00:00 expensidev2004 nginx: 2022/03/22 20:13:58 [error] 164010#164010: *2365 client intended to send too large body: 66021374 bytes, client: 127.0.0.1, server: pdfs.expensify.com.dev, request: "POST /api.php HTTP/1.0", host: "pdfs.expensify.com.dev"
    
  7. 141 remaining items

  8. deleted a comment from melvin-bot on Nov 15, 2022
  9. trjExpensify commented on Nov 15, 2022

    @trjExpensify
    Contributor

    @trjExpensify That is correct, it must have been this PR https://github.com/Expensify/App/pull/10118/files.

    It is hard to check though since this limit is set on servers not even in API so that is why this was missed.

    As in, that explains why it was likely done incorrectly, but nevertheless it's the "offending" PR?

    I agree a comment would be handy but also I think anyone who wants to raise the limit should be wondering why the limit is set to what it it. I have created a quick follow up PR to add a comment there #12738

    Awesome, thanks for adding this!

  10. mountiny commented on Nov 16, 2022

    @mountiny
    Contributor

    As in, that explains why it was likely done incorrectly, but nevertheless it's the "offending" PR?

    It is technically, yes.

  11. flodnv commented on Nov 16, 2022

    @flodnv
    Contributor

    That is correct, it must have been this PR #10118 (files).

    Hm? This PR did not introduce the 50MB...
    image

  12. mountiny commented on Nov 16, 2022

    @mountiny
    Contributor

    :ohnothing:

    Colours were never my strength

  13. mountiny commented on Nov 16, 2022

    @mountiny
    Contributor

    This is the PR which introduced it https://github.com/Expensify/App/pull/4269/files, back in bronze age I believe, judging based off the number of annual rings.

  14. trjExpensify commented on Nov 16, 2022

    @trjExpensify
    Contributor

    Cool, taken care of all the items on the checklist including paying everyone out. Discussion posted here. Will reopen if something comes of that. Thanks everyone! 🎉

  15. trjExpensify commented on Nov 17, 2022

    @trjExpensify
    Contributor

    @Santhosh-Sellavel reminded me that this PR was raised after Nov 4th and was merged on Nov 7th, so we owe @Tushu17 & @Santhosh-Sellavel a $125 bonus each. Offers have been sent here: https://www.upwork.com/jobs/~010f6b384191b40d0c

  16. michaelhaxhiu commented on Nov 17, 2022

    @michaelhaxhiu
    Contributor

    Nice work on getting this one finalized everyone!

  17. trjExpensify commented on Nov 17, 2022

    @trjExpensify
    Contributor

    Cool, done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2EngineeringExternalAdded to denote the issue can be worked on by a contributorImprovementItem broken or needs improvement.ReviewingHas a PR in review

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions