I found the issue in Vite which describes our problem: https://github.com/vitejs/vite/pull/13269
Looking at the release notes of Vite 6 I can see that Vite 6, which was released yesterday, contains the fix. Vite is a dependency of vitest which just gained *support* for Vite 6 with the latest release, but does not require Vite 6 yet and automatically installs Vite 5.
I'd say we live with the workaround of git-ignoring the temporary files (and could add a temporary cleanup step to the "test" script in package.json that removes the files after the tests have run) and wait until after the end of the fundraising campaign (January 2025) to see if there is a new release of Vitest that has Vite 6 as a dependency. If not, we can temporarily specify Vite 6 as a (peer) dependency. For now I think Vite 6 is too "fresh"& a major upgrade that we should not switch to during the campaign.

The long tasks can be different things: on a slow device it could be parsing the actual HTML when we push a large chunks. The way to see what's causing is the trace log. I can collect those from real phones if you could help me with two representative URLs @gabriel-wmde .

Update PR for application: https://github.com/wmde/fundraising-application/pull/3006

Found the cause (mismatched string expectation in db object -> domain entity conversion) and fixed it: https://github.com/wmde/fundraising-donations/pull/258

PR for frontend code changes: https://github.com/wmde/fundraising-app-frontend/pull/541

@kai.nissen Please have a look at the new strings before merging them to test: https://github.com/wmde/fundraising-frontend-content/pull/273

PR for the campaign config: https://github.com/wmde/fundraising-application/pull/3005

I have a strong feeling that this is a a case of floating point approximation, well explained in https://www.theregister.com/2006/08/12/floating_point_approximation/
According to the followup article, the solution (in our case) seems to be to use only integers, like we do in the fundraising app: https://www.theregister.com/2006/09/20/floating_point_numbers_2/
Which might not be compatible with the way JavaScript is storing numbers, it does not have int and float but only number, will have to research that.
There is also a website explicitly dedicated to it https://0.30000000000000004.com/
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html just breaks my brain at the moment

Good news everyone! I thought about this a bit more and ran another test to confirm/falsify my hypothesis of "all that JavaScript execution increases the TBT". I created a test banner where I wrapped our current banner in a 7.5 second timeout. It'll still be loaded by CentralNotice, increasing the Page Transfer Size (which we could avoid for repeat visitors if CN supported sending HTTP cache headers for banners, but that's outside of WMDE's control and needs a separate ticket and discussion in the WMF team that maintains Central Notice), it'll still parse the JavaScript, but the initialization code for the banner would be run outside the "measuring window" (that measures the "Time To Interactive" and then some). The results of the test look very promising: The TBT went down by almost 100ms and is now at pre-banner levels. See for yourself in the comparison of the regular banner with the timeout-banner as the baseline. The cpu.lastLongTask and cpu.totalDuration show even greater improvements. You can of course also look at the individual result of the banner with timeout

Thanks everyone for the support.

In the mean time, we have introduced pagination with the laika theme. And saw that it's not nice. In 2024 we have gone "full circle" with a one-page solution collapsible payment section

This is a vague ideas "Task" document where in hindsight the code quality/dev experience won't be improved by most of the changes outlines. We will do the EnvironmentBootstrapper-related stuff in {T342461: Change environment-specific setup for FunFunFactory}

We now have the "late_campaign" flag to switch it for all banners, the ability to change colors easily (both globally and per-banner). I consider this to be "resolved"

Thanks for the comment, @awight. Good idea to load banner asynchronously, I agree with your assessment and like your proposal.

Hi @Peter, thanks for bringing this to our attention and thanks to @Pcoombe for confirming. The WMDE fundraising campaign started on October 28th, with banners on the English and German Wikipedia geotargeted to visitors form Germany, this matches your observation.

Pull Request: https://github.com/wmde/fundraising-banners/pull/606

Draft PR with lots of remaining errors and TODOs: https://github.com/wmde/fundraising-banners/pull/603

Sorry, my bad for not seeing the radio label gap, I applied the fix to the wrong file :facepalm:
Fix is deployed now.
Also, the banner server now supports cookie setting on "I already donated".

I've adressed all the issues except two:

It's now fully testable with tracking for the fee (it's tracked when submitting, the evnt is called "cover-transaction-fee").

@kai.nissen You can now user-test this to get a first impression. How will the campaigns team know if people clicked the transaction fee? By the decimal points in the donation sums? Or will they measure if the donation amount is higher for VAR (which would be just ~1% even if most people clicked the checkbox)

The first round of error logging pinpointed to the donation repository as the source of errors. I've investigated and identified the database-entity-to-domain-entity-conversion as the most likely culprit. Unfortunately, we don't log enough information to see what excactly went wrong during the conversion, so we'll have to do another dance of

1. Review Pull request https://github.com/wmde/fundraising-donations/pull/255
2. Create new patch release of Donation bounded context
3. Update donation bounded context in app (manually, dependabot is not active for that repo)
4. Deploy
5. Trigger the IPN again

No longer needed, since we're using Woodpecker CI now on our own infrastructure. Woodpecker uses containers to run and we package kontocheck in our CI container. Spinning it off into its own service might be an idea to keep our PHP version as close to the released one as possible, but sicne we're also using MongoDB which is not part fo the standard distribution we might as well go "All in" with our custom PHP environment.

We're using Woodpecker CI now (on our own infratsructure)

@kai.nissen This new feature interacts with the "upsell" feature and needs more specification for the 2nd and 3d form page:

• What should be displayed on the 2nd page (when we try to "upsell")? Should it be the original amount or the amount + fee? The latter would need duplicated components of the 2nd page that can take the new info in. If we don't display the adapted amount, do we "undo" the checkbox or do we silently add the fee when submitting?
• What do we do on the 3rd form page (upsell with custom amount input)? Do we dynamically update the transaction fee? Do we drop it? What happens if the user does not wait for the total to update and just hits submit? We might need UX input here.

We could also test this feature without the "upsell" in the banner. Please discuss the increased complexity with the campaigns team and make them aware that in this case the complexity (and effort to implement) goes up because two featues are interacting. Another option would be to activate the checkbox only for one-time donations.

Done & Deployed.
PR for updating the deployment playbook: https://github.com/wmde/fundraising-infrastructure/pull/431
PR for updating the server initialization playbook: https://github.com/wmde/fundraising-infrastructure/pull/432

Deployed to https://testing05.wikimedia.customers.manitu.net

I'm moving this into "Deploy to Test", since the code review went through and we will address remaining snag (mentioned in the code review) in T376311: Adapt payment summary at the bottom of the donation form

Thank you so much!