Skip to content

[HOLD for payment 2024-04-25] Attachment - Wrong PDF is opened #39833

Closed

Description

@lanitochka17

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: 1.4.60-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

  1. Navigate to any report
  2. Send two pdf files
  3. Open the last one

Expected Result:

The last pdf file should be opened

Actual Result:

The first pdf file is opened

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6442231_1712580406073.Screen_Recording_2024-04-08_at_3.44.37_in_the_afternoon.mp4

View all open jobs on GitHub

Activity

  1. melvin-bot commented on Apr 8, 2024

    @melvin-bot

    Triggered auto assignment to @amyevans (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

  2. github-actions commented on Apr 8, 2024

    @github-actions
    Contributor

    👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  3. lanitochka17 commented on Apr 8, 2024

    @lanitochka17
    Author

    @amyevans FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

  4. amyevans commented on Apr 8, 2024

    @amyevans
    Contributor

    I verified by reverting #39578 locally that it's the source of the regression cc @abzokhattab @hungvu193 @flodnv.

    Since the package bump PR is tied to a rather non-urgent bug fix I think it makes the most sense to just revert the bump PR, but speak up soon if you disagree.

  5. amyevans commented on Apr 9, 2024

    @amyevans
    Contributor
  6. hungvu193 commented on Apr 9, 2024

    @hungvu193
    Contributor

    Hey @amyevans I can reproduce even when I downgrade react-fast-pdf to 1.0.6

  7. hungvu193 commented on Apr 9, 2024

    @hungvu193
    Contributor
    Screen.Recording.2024-04-09.at.09.14.09.mov
  8. amyevans commented on Apr 9, 2024

    @amyevans
    Contributor

    Can you verify the version is "version": "1.0.6", within /node_modules/react-fast-pdf/package.json? You'd likely need to delete your node_modules folder and run npm ci to get it to "downgrade" to 1.0.6

  9. 8 remaining items

  10. amyevans commented on Apr 9, 2024

    @amyevans
    Contributor

    Testing on:

    This branch + react-fast-pdf 1.0.8:

    pr-39930-and-1-0-8.mov

    The behavior is inconsistent, but it usually seems to do what's in the recording: briefly flashes the wrong attachment before loading the correct (most recent) one.

    main + react-fast-pdf 1.0.6:

    main-and-1-0-6.mov

    Bug is not reproducible.

    main + react-fast-pdf 1.0.7:

    main-and-1-0-7.mov

    Bug is reproducible.

    While perhaps the root cause might be similar to what's being worked on in #39930, I don't think it is coincidental that the bug manifests on 1.0.7 but not on 1.0.6, so I still think proceeding with the revert is the right course of action. Do you all agree or disagree? Cc @Julesssss as well as deployer this week

  11. amyevans commented on Apr 9, 2024

    @amyevans
    Contributor

    Alright I retested on staging following the CP: #39869 (comment). I think we can close this one out, thanks for the discussion!

  12. kidroca commented on Apr 11, 2024

    @kidroca
    Contributor

    Should we open and track an issue for react-fast-pdf or maybe have a note that the library shouldn't be updated since a bug manifests in more recent versions?

  13. amyevans commented on Apr 11, 2024

    @amyevans
    Contributor

    Yes, I believe they're working on a patch in the original issue but I left a note (#34816 (comment)) to clarify expectations.

  14. added
    Awaiting PaymentAuto-added when associated PR is deployed to production
    and removed on Apr 18, 2024
  15. changed the title [-] Attachment - Wrong PDF is opened[/-] [+][HOLD for payment 2024-04-25] Attachment - Wrong PDF is opened[/+] on Apr 18, 2024
  16. melvin-bot commented on Apr 18, 2024

    @melvin-bot

    Reviewing label has been removed, please complete the "BugZero Checklist".

  17. melvin-bot commented on Apr 18, 2024

    @melvin-bot

    The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.62-17 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

    If no regressions arise, payment will be issued on 2024-04-25. 🎊

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

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions