View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0009770Talermerchant backendpublic2025-04-22 16:132026-01-25 12:23
Reportersebasjm Assigned ToChristian Grothoff  
PriorityhighSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Versiongit (master) 
Target Version1.4Fixed in Version1.4 
Summary0009770: merchant backend kyc state doesn't wait for longpolling [5d]
Descriptionmerchant spa will wait 5 seconds before doing a request again


https://docs.taler.net/core/api-merchant.html#get--instances-$INSTANCE-private-kyc


$ time curl 'http://merchant.taler.test:1180/private/kyc?timeout_ms=15000&lpt=3' -H 'Authorization: Bearer secret-token:WY4FBT6NK2KC5F4CPZGQ1J230V9BJX7Q41DRAZETX9P7K820RWRG'
{
...
}
real 0m0.020s
user 0m0.008s
sys 0m0.009s
Tagsux

Relationships

related to 0010627 resolvedsebasjm For exchanges w/ KYC: taler-merchant-kyccheck and "KYC Status" in the UI can be brought out of touch; leading to various issues 

Activities

Christian Grothoff

2025-10-28 13:21

manager   ~0026263

Looking at the code, it does seem to implement long-polling correctly. In which state is the account here (as in: what response do you see?). IMO there is one case that is not long-pollable by-design right now, which is IF we are in state "KYC OK", we always return immediately. So the SPA basically cannot wait for KYC to transition from "OK" to "needs-work". At the exchange, that's intended (hence the "lpt" values only go up to 3 there) because we won't want merchants to long-poll on the KYC state if everything is already fine (would create too many open connections, plus we can signal that something goes wrong with the specific transaction).
For the merchant SPA talking to the merchant backend, we could conceivably have long-polling also for a transition from "OK" to "not OK", but for that we'd need to add an lpt=4 case.

Is that the issue here, or is the long-polling broken on some other case and I just don't see it? Please clarify!

sebasjm

2025-11-11 15:55

developer   ~0026378

--- spa is not expecting 'ok to needs-to-work', actually is from 'kyc-required' to 'be-ok'

after receiving a response with MerchantAccountKycRedirect[] i check every status for a `getLongPollingReason`
if there is a reason to do long polling (the first one it found) it stays doing it.

the only reason it could do long polling is because the server responded with an account with KYC_REQUIRED
https://git.taler.net/taler-typescript-core.git/tree/packages/merchant-backoffice-ui/src/hooks/instance.ts#n233
(to_be_ok is lpt = 3)

-- new example

in my setup, the merchant needs a kyb process

$ time curl 'http://merchant.taler.test/private/kyc?timeout_ms=5000&lpt=3' -H 'Authorization: Bearer secret-token:CEQDN7P9217ZWEDG46PKFKXGXMVY3P6VFFJX6ZCYNFG2SXETF3N0'
{
  "kyc_data": [
    {
      "payto_uri": "payto://iban/DE1327812254798?receiver-name=the%20name%20of%20merchant",
      "h_wire": "3D471873DVTQ9K76CA8CBTK3EP3NM42W9XVFKCB1S2TCZMCA3W2GNGRJM8QQ7M9HK80PT1DQQB4KQV0Y7MHGQMAVJRHT1CB3TGWNHPR",
      "status": "kyc-required",
      "exchange_url": "http://exchange.taler.test/",
      "no_keys": false,
      "auth_conflict": false,
      "exchange_http_status": 200,
      "access_token": "E8NY045SNX3YD6AY3GM6W5WKVBD1Y8SBNGPTJE5759S9K8J3PM4G",
      "limits": [
        {
          "threshold": "KUDOS:100",
          "timeframe": {
            "d_us": 86400000000
          },
          "soft_limit": true,
          "operation_type": "AGGREGATE"
        },
        {
          "threshold": "KUDOS:0",
          "timeframe": {
            "d_us": 86400000000
          },
          "soft_limit": true,
          "operation_type": "DEPOSIT"
        },
        {
          "threshold": "KUDOS:10",
          "timeframe": {
            "d_us": 86400000000
          },
          "soft_limit": true,
          "operation_type": "WITHDRAW"
        }
      ]
    }
  ]
}
real 0m0.022s
user 0m0.005s
sys 0m0.014s

sebasjm

2025-11-20 12:35

developer   ~0026562

> plus we can signal that something goes wrong with the specific transaction

If the SPA is open and at the same time a wallet tries to make a deposit that makes the account go to a kyc-required state then the SPA will not notice until reload.
I could make the backoffice query N seconds but maybe a long-polling when the account is ready is not a bad idea, since the merchant want to know this ASAP.

We could also send email / phone sms based on a flag instead.

Christian Grothoff

2026-01-25 08:15

manager   ~0027335

The kyclp branch and the *vKYCLP* protocol version (likely still v25?) now have new long polling arguments:
1) You can long-poll for *any* change to the KYC status (basically, Etag and If-not-modified + long-poller). This "lp_not_etag" is likely what you want to use most of the time. It also works on 204, so you can learn that bank accounts were added in the first place.
2) You can long-poll for the *status* field, to either no-longer be a particular value, or for it to become a particular value (useful mostly if you do the status to change for a particular exchange).

With these, I think the bug can safely be assigned to Sebastian to make SPA changes for better long-polling once the branch is merged.

Christian Grothoff

2026-01-25 12:23

manager   ~0027336

Branch merged, what should be left is updating the SPA to use the new long-polling capabilities.

Issue History

Date Modified Username Field Change
2025-04-22 16:13 sebasjm New Issue
2025-04-22 16:13 sebasjm Status new => assigned
2025-04-22 16:13 sebasjm Assigned To => Christian Grothoff
2025-04-22 19:27 sebasjm Assigned To Christian Grothoff =>
2025-04-22 19:27 sebasjm Status assigned => confirmed
2025-04-25 07:15 Christian Grothoff Assigned To => Christian Grothoff
2025-04-25 07:15 Christian Grothoff Status confirmed => assigned
2025-04-27 13:01 Christian Grothoff Assigned To Christian Grothoff =>
2025-04-27 13:01 Christian Grothoff Status assigned => confirmed
2025-04-27 13:01 Christian Grothoff Target Version 1.0 stretch goals => post-1.0
2025-06-08 20:25 Christian Grothoff Tag Attached: ux
2025-10-23 12:52 Christian Grothoff Assigned To => Christian Grothoff
2025-10-23 12:52 Christian Grothoff Status confirmed => assigned
2025-10-23 12:52 Christian Grothoff Status assigned => confirmed
2025-10-23 17:54 Christian Grothoff Priority normal => high
2025-10-26 13:54 Christian Grothoff Status confirmed => assigned
2025-10-28 13:21 Christian Grothoff Note Added: 0026263
2025-10-28 13:21 Christian Grothoff Assigned To Christian Grothoff => sebasjm
2025-10-28 13:21 Christian Grothoff Status assigned => feedback
2025-11-11 15:55 sebasjm Note Added: 0026378
2025-11-11 15:56 sebasjm Assigned To sebasjm => Christian Grothoff
2025-11-11 15:56 sebasjm Status feedback => confirmed
2025-11-11 15:56 sebasjm Priority high => normal
2025-11-11 15:57 sebasjm Priority normal => high
2025-11-19 16:57 Christian Grothoff Relationship added related to 0010627
2025-11-20 12:35 sebasjm Note Added: 0026562
2025-11-28 22:15 Christian Grothoff Summary merchant backend kyc state doesn't wait for longpolling => merchant backend kyc state doesn't wait for longpolling [5d]
2026-01-25 07:51 Christian Grothoff Status confirmed => assigned
2026-01-25 08:15 Christian Grothoff Note Added: 0027335
2026-01-25 12:23 Christian Grothoff Status assigned => resolved
2026-01-25 12:23 Christian Grothoff Resolution open => fixed
2026-01-25 12:23 Christian Grothoff Fixed in Version => 1.4
2026-01-25 12:23 Christian Grothoff Note Added: 0027336
2026-01-25 12:23 Christian Grothoff Target Version post-1.0 => 1.4