View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011691 | Taler | merchant backend | public | 2026-07-27 21:30 | 2026-07-29 12:13 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | feedback | 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. | ||||
|
|
@Sebastian: I'm not sure what's wrong with (b) to be honest. Since the long-polling mechanism is always free to return *fewer* rows than the one requested, you'd *have* to implement a code path to implement the second request anyway! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-07-27 21:30 | sebasjm | New Issue | |
| 2026-07-27 21:30 | sebasjm | Status | new => assigned |
| 2026-07-27 21:30 | sebasjm | Assigned To | => Florian Dold |
| 2026-07-27 21:33 | sebasjm | Assigned To | Florian Dold => Christian Grothoff |
| 2026-07-29 12:06 | Florian Dold | Note Added: 0029299 | |
| 2026-07-29 12:13 | Florian Dold | Assigned To | Christian Grothoff => sebasjm |
| 2026-07-29 12:13 | Florian Dold | Status | assigned => feedback |
