View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009770 | Taler | merchant backend | public | 2025-04-22 14:13 | 2026-02-04 19:00 |
| Reporter | sebasjm | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 1.4 | Fixed in Version | 1.4 | ||
| Summary | 0009770: merchant backend kyc state doesn't wait for longpolling [5d] | ||||
| Description | merchant 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 | ||||
| Tags | ux | ||||
| 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! | |
| --- 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 | |
| > 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. | |
| 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. | |
| Branch merged, what should be left is updating the SPA to use the new long-polling capabilities. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-04-22 14:13 | sebasjm | New Issue | |
| 2025-04-22 14:13 | sebasjm | Status | new => assigned |
| 2025-04-22 14:13 | sebasjm | Assigned To | => Christian Grothoff |
| 2025-04-22 17:27 | sebasjm | Assigned To | Christian Grothoff => |
| 2025-04-22 17:27 | sebasjm | Status | assigned => implementing |
| 2025-04-25 05:15 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-04-25 05:15 | Christian Grothoff | Status | implementing => assigned |
| 2025-04-27 11:01 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-04-27 11:01 | Christian Grothoff | Status | assigned => implementing |
| 2025-04-27 11:01 | Christian Grothoff | Target Version | 1.0 stretch goals => post-1.0 |
| 2025-06-08 18:25 | Christian Grothoff | Tag Attached: ux | |
| 2025-10-23 10:52 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-10-23 10:52 | Christian Grothoff | Status | implementing => assigned |
| 2025-10-23 10:52 | Christian Grothoff | Status | assigned => implementing |
| 2025-10-23 15:54 | Christian Grothoff | Priority | normal => high |
| 2025-10-26 12:54 | Christian Grothoff | Status | implementing => assigned |
| 2025-10-28 12:21 | Christian Grothoff | Note Added: 0026263 | |
| 2025-10-28 12:21 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2025-10-28 12:21 | Christian Grothoff | Status | assigned => feedback |
| 2025-11-11 14:55 | sebasjm | Note Added: 0026378 | |
| 2025-11-11 14:56 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2025-11-11 14:56 | sebasjm | Status | feedback => implementing |
| 2025-11-11 14:56 | sebasjm | Priority | high => normal |
| 2025-11-11 14:57 | sebasjm | Priority | normal => high |
| 2025-11-19 15:57 | Christian Grothoff | Relationship added | related to 0010627 |
| 2025-11-20 11:35 | sebasjm | Note Added: 0026562 | |
| 2025-11-28 21: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 06:51 | Christian Grothoff | Status | implementing => assigned |
| 2026-01-25 07:15 | Christian Grothoff | Note Added: 0027335 | |
| 2026-01-25 11:23 | Christian Grothoff | Status | assigned => informing |
| 2026-01-25 11:23 | Christian Grothoff | Resolution | open => fixed |
| 2026-01-25 11:23 | Christian Grothoff | Fixed in Version | => 1.4 |
| 2026-01-25 11:23 | Christian Grothoff | Note Added: 0027336 | |
| 2026-01-25 11:23 | Christian Grothoff | Target Version | post-1.0 => 1.4 |
| 2026-02-04 19:00 | Christian Grothoff | Status | informing => closed |