View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011691 | Taler | merchant backend | public | 2026-07-27 21:30 | 2026-07-27 21:33 |
| Reporter | sebasjm | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Summary | 0011691: order long polling only returns on new_orders | ||||
| Description | from spec https://docs.taler.net/core/api-merchant.html#get-[-instances-$INSTANCE]-private-orders limit – Optional. At most return the given number of results. Negative for descending by row ID, positive for ascending by row ID. Default is 20. Since protocol v12. timeout_ms – Optional. Timeout in milliseconds to wait for additional orders if the answer would otherwise be negative (long polling). Only useful if limit is positive. Note that the merchant MAY still return a response that contains fewer than limit orders. That makes the long polling more complicated from the client side leaving to 2 solutions: a) merge LP result set with old a.1) first request limit=-20 a.2) second request limit=5&timeout=15000&offset=first_row (LP) a.3) if LP returns size > 0 merge with previous result b) use LP as a signal a.1) first request limit=-20 a.2) second request limit=1&timeout=15000 (LP) a.3) if LP returns size > 0 repeat the first request with (a) returns only when there is a new order. if and order in the resultset of (a.1) is paid the SPA doesn't notice with (b) update the full resultset but SPA makes 2 request solution: timeout_ms should also work with limit is negative & offset is empty "the latest N values after an update" >That makes the long polling more complicated There is a merge operation required by the client making the request should be done in the server. | ||||
| Tags | No tags attached. | ||||
