@cjming Thanks for making this task!
If I may propose another acceptance criterion that would make the library even more robust:

• If stream config has not been received yet, then events should be enqueued, instead of dropped.

This could be done by having another (secondary) queue at the front of the submitMetricsEvent() function that queues up events in case the stream config hasn't been loaded, and then drain the queue upon receipt of stream config.
We could also refactor the current (single) queue to accept all events, regardless of the presence of stream config, and then upon emptying the queue perform the logic of filtering events that should/shouldn't be sent.

I believe I may have an answer to the question of missing events:
TLDR: a race condition in the Metrics Platform client library.

Cleaning up some very old and/or no-longer-relevant tasks.

Cleaning up some very old and/or no-longer-relevant tasks.

Is it possible for the information typically shown in the email subject to be included in the body of the email, similar to how it is done in iOS?

@Prototyperspective Here is what I see for the article you linked:

Notes for QA:
To test that the feature flag for Japan is working, please use the production release candidate:
https://releases.wikimedia.org/mobile/android/wikipedia/stable/wikipedia-2.7.50486-r-2024-05-14.apk

@ABorbaWMF Please note the new Beta released today, updated in the task description.

notes for QA:
This is purely a tech-debt task to rearrange the code into more modern patterns. There are no expected changes to the behavior, so this can just be covered automatically by regression tests.

In T363860#9791315, @HNordeenWMF wrote:

I ran into an issue where the large amount error does not show/register for non USD currencies

In T363860#9791422, @Pcoombe wrote:

I was able to make a 2 GBP donation! Received my thank you email, and the utm tracking info all looks right

However I noticed that in the dark themes some of the text is unreadable:

All good catch(es), @Tsevener

In T362698#9765134, @cmadeo wrote:

Hi @Dbrant unfortunately the link above isn't working for me

Navigating manually to Special:Nearby is not supported in the app.
The app has an entirely separate feature called Places, which you can access from the More menu (bottom-right in the main screen).

In T363860#9759467, @HNordeenWMF wrote:

I'm seeing something weird related to number formatting of the amount vs error message

@cmadeo Done - here is the latest beta/live apk for testing:
https://drive.google.com/file/d/1XrAsMaHGzzGRHev_VqeZ_-v7L9bvej0o/view?usp=sharing

In T362698#9758006, @cmadeo wrote:

• When I select "I'll generously add $0.35 to cover the transaction fees..." that amount is not added to the total in the input field

Will do! (Under the current logic it will add the $0.35 under the hood when submitting the final amount, but totally agree that the text field itself should be the source of truth for the final amount)

These items are available, by scrolling to the bottom "About this article" section and selecting "Page issues".

most current apk:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/8883906033

Blocking workflow using Twinkle:
https://drive.google.com/file/d/1F7EmD9yjpXJ6yK3pT8H2-LDiv08orUbf/view?usp=sharing

An APK is now available for testing:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/8850286281

In T361122#9671201, @Dbrant wrote:

• Design and build the user interface for initiating and completing the transaction, while using a sandbox "test" environment provided by Google Pay, without yet needing to communicate with our backend API.
  • If necessary, we can try making sample payment requests to a backend staging environment that FR-tech can set up. This testing can be in parallel with development of the user interface.
• Take screenshots of each step of the completed workflow and submit them for approval.
• Once approved, we can switch from the "test" environment to the production GPay environment.
• The end result of a GPay transaction is a token that we will forward to FR-tech's existing payments backend, which will complete the transaction.
  • At this stage we will do final testing to see how our backend handles this token, and see if any tweaks need to be made.

looks like a duplicate of T347582.

As discussed, repurposing this task as the engineering task. (thx so much @aishwaryavardhana)

At the end of the login sequence on mobile web, it redirects the user to /wiki/Special:CentralLogin/complete?token=...
The app intercepts this URL (because it's configured to intercept all paths that start with /wiki/). But once the app sees that this is a Special page, it bounces it back out to the browser app, but by this point the request is missing some crucial bits of state (headers? referer?) that cause it to show the strange error.