Page MenuHomePhabricator

[cashtab] Improve PayButton user experience
ClosedPublic

Authored by Fabien on Aug 18 2025, 21:56.

Details

Reviewers
bytesofman
Group Reviewers
Restricted Project
Commits
rABC905accce6b98: [cashtab] Improve PayButton user experience
Summary

By broadcasting the to appropriated node so the notifaction comes with no delay.

Test Plan
./contrib/teamcity/build-configurations.py cashtab-tests

Diff Detail

Repository
rABC Bitcoin ABC
Branch
cashtab_paybutton
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 34182
Build 67832: Build Diffcashtab-tests
Build 67831: arc lint + arc unit

Event Timeline

Rebase, fix and more logs

We're still working on the CORS error but upon PB chronik msg failure, we should still continue to clear out the Send inputs like normal. Also don't bother throwing an error - it just spooks people and PB doesn't necessarily need our own node online for stuff to work since we might be doing an upgrade or something, falling back to other public nodes.

Good news - we got the CORS issue sorted out so that's working now.

Bad news - no latency improvement in my testing.

Good news (2) - our chronik node is detecting the tx very quickly (0.1-0.2s) so we're going to take a look at what's going on there and report back.

We're still working on the CORS error but upon PB chronik msg failure, we should still continue to clear out the Send inputs like normal. Also don't bother throwing an error - it just spooks people and PB doesn't necessarily need our own node online for stuff to work since we might be doing an upgrade or something, falling back to other public nodes.

The code doesn't show any error if it fails. It's just trying but since it's not mandatory for proper operation the result is ignored. It's also normal if it fails, it might just know about the tx already due to other nodes relaying it.

We're still working on the CORS error but upon PB chronik msg failure, we should still continue to clear out the Send inputs like normal. Also don't bother throwing an error - it just spooks people and PB doesn't necessarily need our own node online for stuff to work since we might be doing an upgrade or something, falling back to other public nodes.

The code doesn't show any error if it fails. It's just trying but since it's not mandatory for proper operation the result is ignored. It's also normal if it fails, it might just know about the tx already due to other nodes relaying it.

There's a red error toast in the UI for me when it happens.

We're still working on the CORS error but upon PB chronik msg failure, we should still continue to clear out the Send inputs like normal. Also don't bother throwing an error - it just spooks people and PB doesn't necessarily need our own node online for stuff to work since we might be doing an upgrade or something, falling back to other public nodes.

The code doesn't show any error if it fails. It's just trying but since it's not mandatory for proper operation the result is ignored. It's also normal if it fails, it might just know about the tx already due to other nodes relaying it.

There's a red error toast in the UI for me when it happens.

Oh OK, can you paste the error ? I will catch it

We're still working on the CORS error but upon PB chronik msg failure, we should still continue to clear out the Send inputs like normal. Also don't bother throwing an error - it just spooks people and PB doesn't necessarily need our own node online for stuff to work since we might be doing an upgrade or something, falling back to other public nodes.

The code doesn't show any error if it fails. It's just trying but since it's not mandatory for proper operation the result is ignored. It's also normal if it fails, it might just know about the tx already due to other nodes relaying it.

There's a red error toast in the UI for me when it happens.

Oh OK, can you paste the error ? I will catch it

Now that we fixed the cors issues... I'm not sure how to get it to fail on our end to grab a screenshot but maybe you can try updating the URL to something totally invalid and seeing if that displays the error toast. I don't remember the exact error message but it's something along the lines of being "unable to connect to known nodes".

Good news though - my test issue yesterday might have been some weird caching because we're able to confirm that speed is great now. For me, it cut the latency in half.

Assuming we decide to go ahead with our direct-to-chronik paybutton branch (on our end), we're going to make sure we're prioritizing our own node rather than using the "Closest" strategy.

If we can get that error toast sorted out, this LGTM.

Remove all debug logs, prevent the toast error

Note that there is no test for this feature, for a couple reasons:

  • It would require a whole new mock and whiteboxing refactor to do so, which seems overkill
  • This feature can fail with no impact on the user, only a small additional delay (maybe 1s to 2s)
Fabien published this revision for review.Aug 25 2025, 12:54
bytesofman added inline comments.
cashtab/src/transactions/index.js
208 ↗(On Diff #55337)

won't we already have broadcast the tx here?

217 ↗(On Diff #55337)

so, could expect this to fail if the paybutton server already saw it

silently handled but seems like an unnecessary delay, shouldn't an isPaybutton tx only try to broadcast to paybutton, mb if that fails, try await chronik.broadcastTx(hex, isBurn);

cashtab/src/transactions/index.js
208 ↗(On Diff #55337)

Yes we do, the code adds an extra broadcast. It's a best effort for sharing the tx with the paybutton node directly in order to reduce the latency.

217 ↗(On Diff #55337)

I think we always want the normal broadcast to infra nodes that we support. This ensure the proper behavior, while the extra broadcast is only an latency optimization. If the optimization fails the paybutton will work just fine, it might just take a bit longer to give feedback.

This revision is now accepted and ready to land.Aug 26 2025, 18:13
This revision was automatically updated to reflect the committed changes.