View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0009770Talermerchant backendpublic2025-04-22 16:132025-11-20 12:35
Reportersebasjm Assigned ToChristian Grothoff  
PriorityhighSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Versiongit (master) 
Target Versionpost-1.0 
Summary0009770: merchant backend kyc state doesn't wait for longpolling
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 confirmed 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.

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