You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HOLD for payment 2024-04-25] Attachment - Wrong PDF is opened #39833
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:
Navigate to any report
Send two pdf files
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?
👋 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:
Identify the pull request that introduced this issue and revert it.
@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
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.
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
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
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?
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:
Activity
melvin-bot commentedon Apr 8, 2024
Triggered auto assignment to @amyevans (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.github-actions commentedon Apr 8, 2024
👋 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:
lanitochka17 commentedon Apr 8, 2024
@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
amyevans commentedon Apr 8, 2024
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.
amyevans commentedon Apr 9, 2024
PR has been merged but waiting on CP: https://expensify.slack.com/archives/C07J32337/p1712628550724549
hungvu193 commentedon Apr 9, 2024
Hey @amyevans I can reproduce even when I downgrade react-fast-pdf to 1.0.6
hungvu193 commentedon Apr 9, 2024
Screen.Recording.2024-04-09.at.09.14.09.mov
amyevans commentedon Apr 9, 2024
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 runnpm cito get it to "downgrade" to 1.0.68 remaining items
amyevans commentedon Apr 9, 2024
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
amyevans commentedon Apr 9, 2024
Alright I retested on staging following the CP: #39869 (comment). I think we can close this one out, thanks for the discussion!
kidroca commentedon Apr 11, 2024
Should we open and track an issue for
react-fast-pdfor maybe have a note that the library shouldn't be updated since a bug manifests in more recent versions?amyevans commentedon Apr 11, 2024
Yes, I believe they're working on a patch in the original issue but I left a note (#34816 (comment)) to clarify expectations.
[-] Attachment - Wrong PDF is opened[/-][+][HOLD for payment 2024-04-25] Attachment - Wrong PDF is opened[/+]melvin-bot commentedon Apr 18, 2024
Reviewinglabel has been removed, please complete the "BugZero Checklist".melvin-bot commentedon Apr 18, 2024
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. 🎊