View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008745 | Taler | mechant backend | public | 2024-04-16 19:53 | 2024-05-15 18:01 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Product Version | 0.11 | ||||
| Target Version | 0.11 | Fixed in Version | 0.11 | ||
| Summary | 0008745: long polling does not return when refund is made [4h] | ||||
| Description | in this request [1] wallet is waiting for auto refund knowing that already NETZBON:2 was refunded. while waiting for 10 secs, the merchant makes a refund of NETZBON:1 but the request still waiting 10 secs i expected the request to automatically stop when the merchant create the refund $ time curl "http://merchant.taler.test:1180/orders/2024.107-024C9VRZ8FHFE?h_contract=Z2E9FC5KYVFNCN729CQTAQJ95GY8CCN3H9CA8RYW28MJTP71GAZ3ZB293FPBYSZC510ZEF2S0RSQTQMV89K1FTR4T4PE2TAB8RQ9Z40&timeout_ms=10000&await_refund_obtained=yes&refund=NETZBON%3A2" { "refunded": true, "refund_pending": true, "refund_taken": "NETZBON:2", "refund_amount": "NETZBON:3" } real 0m10.012s user 0m0.000s sys 0m0.004s | ||||
| Tags | No tags attached. | ||||
|
|
If the refund is already 2, giving a refund over 1 probably does nothing, as AFAIK the refund amount is expected to always be the maximum of all POSTed amounts (not the SUM!). This is for idempotency: posting a refund of 2 twice will do the same as refunding only 2. So if you did refund 2 and then refund 1, the refund over 1 will just be ignored and do nothing. To refund a total of 3, you need to refund 2 and then refund 3. If you did not do that correctly, then the refund 1 did nothing and so the merchant is correct to not wake up the wallet for no change in refund total. *BUT* if the wallet then did get a refund over 3, we have an issue that either the MAX logic is not working correctly, or you did the correct request and the notification logic is broken. But the code *looks* correct. It would be good if you could write a proper test case... |
|
|
> If the refund is already 2, giving a refund over 1 probably does nothing Correct, merchant SPA add up before sending the request. This works as you described. > if the wallet then did get a refund over 3, we have an issue that either the MAX logic is not working correctly, or you did the correct request and the notification logic is broken. But the code *looks* correct. It would be good if you could write a proper test case... This seems to be the case since the wallet IS getting the correct refund. The problem is the time it takes, no the amount. I will add a test and assign back. |
|
|
there is a test in harness for auto refund that takes 10 secs, those 10 secs correspond to the wallet waiting the merchant to reply the long polling. # taler-harness run-integrationtests refund-auto ... lot of logs... parent: got result {"name":"refund-auto","timeSec":13.578,"status":"pass"} See /tmp/taler-integrationtests-KSqp8Q/results.json for details Skipped: 0/1 Failed: 0/1 Passed: 1/1 $ grep await_refund /tmp/taler-integrationtests-KSqp8Q/refund-auto/wallet-wallet-stderr.log 2024-05-13T14:59:28.293Z http-impl.node.ts TRACE Requesting GET http://localhost:8083/orders/2024.134-01R0AN1BQ01AM?h_contract=10CZHCNM5G8K29N0TKG6377QQY5C3XC5QSH2JXXVNF0MKZ24FM9A107MTXW7FHMKZDNT2XDVF4EQJBM3JVQPQMD2KM76BH60CQ0WQ58&timeout_ms=10000&await_refund_obtained=yes&refund=TESTKUDOS%3A0 refund request param is TESTKUDOS:0 (so the long polling is waiting for any refund) and a refund was made before calling so I expect this to return immediately. |
|
|
Eh, why do you set 'await_refund_obtained=yes'? That instructs the merchant backend to BLOCK on the request until all awarded refunds have been obtained by the wallet. So as you just now gave the wallet a higher refund (but did not fetch it, presumably), the request legitimately blocks. Did you maybe not understand await_refund_obtained? |
|
|
ACK, not sure why this flags is there. Looks like it was misunderstood. this request is not waiting for the refund to be picked up, is waiting for a refund to be offered. Closing |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-04-16 19:53 | sebasjm | New Issue | |
| 2024-04-16 19:53 | sebasjm | Status | new => assigned |
| 2024-04-16 19:53 | sebasjm | Assigned To | => Christian Grothoff |
| 2024-04-16 20:05 | sebasjm | Relationship added | related to 0008746 |
| 2024-04-23 18:09 | Christian Grothoff | Summary | long polling does not return when refund is made => long polling does not return when refund is made [4h] |
| 2024-05-13 12:25 | Christian Grothoff | Note Added: 0022398 | |
| 2024-05-13 12:25 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-05-13 12:25 | Christian Grothoff | Status | assigned => feedback |
| 2024-05-13 14:54 | sebasjm | Note Added: 0022402 | |
| 2024-05-13 17:23 | sebasjm | Note Added: 0022403 | |
| 2024-05-13 17:24 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2024-05-13 17:40 | Christian Grothoff | Note Added: 0022407 | |
| 2024-05-13 17:40 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2024-05-13 18:06 | sebasjm | Note Added: 0022408 | |
| 2024-05-13 18:06 | sebasjm | Status | feedback => resolved |
| 2024-05-13 18:06 | sebasjm | Resolution | open => no change required |
| 2024-05-13 21:14 | Christian Grothoff | Fixed in Version | => 0.11 |
| 2024-05-15 18:01 | Christian Grothoff | Status | resolved => closed |
