View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011691 | Taler | merchant backend | public | 2026-07-27 21:30 | 2026-07-30 15:54 |
| Reporter | sebasjm | Assigned To | Florian Dold | ||
| 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 (original) a.2) second request limit=5&timeout=15000&offset=first_row (LP) a.3) if LP returns size > 0 then merge with previous result a.4) go to (a.2) // the __original__ request is NOT on the loop b) use LP as a signal b.1) first request limit=-20 (original) b.2) second request limit=1&timeout=15000 (LP) b.3) if LP returns size > 0 go to (b.1) else go to (b.2) // the __original__ request is on the loop 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! |
|
|
> @Sebastian: I'm not sure what's wrong with (b) to be honest. the (b) path has an additional request (b.3) after LP request returned (b.3) repeat the original request to get an up-to-date list of the latest 20 elements. But I think from the spec perspective: 1) consistency: https://docs.taler.net/core/api-merchant.html#get-[-instances-$INSTANCE]-orders-$ORDER_ID https://docs.taler.net/core/api-merchant.html#get-[-instances-$INSTANCE]-sessions-$SESSION_ID?fulfillment_url=$URL https://docs.taler.net/core/api-merchant.html#get--management-instances-$INSTANCE-kyc https://docs.taler.net/core/api-exchange.html#get--reserves-$RESERVE_PUB https://docs.taler.net/core/api-exchange.html#get--deposits-$H_WIRE-$MERCHANT_PUB-$H_CONTRACT_TERMS-$COIN_PUB https://docs.taler.net/core/api-corebank.html#get--withdrawals-$WITHDRAWAL_ID The spec is different to other long polling request where the client makes the __ same __ request (maybe also plus an etag) to receive an up-to-date response ASAP 2) missing info: Since the LP request have different semantic than the original request (original request: get me the latest 20, lp request: get me new after this offset) the client doesn't have any alternative that repeat the original request if we want to keep the list updated in the UI. For example in the merchant order list the SPA is showing the latest 20 unpaid orders. It only listen for merchant creating new orders but is not updated when any of the orders is paid. If we change the spec as I suggested (original request without timeout_ms: "get me the latest 20 right now", lp request with timeout: "get me the latest 20 after any update or timeout" ) we fix both issues: - (a) is up to the server include updates in elements on the list - (b) client doesn't need an extra request to update the full list ============================= > but hey sebastian, not all the list requires returning update on elements on the list and we may be also returning 20 elements in the response body when only 1 element change. This is more efficient! That's fair, but I think a more stable spec is far better than bytes consumed in this case. More stable in the sense that the LP request reflect the client app objective: keep the original resulset up to date. In the hypothetical case that we want `merchant unpaid orders list` to be updated when an order in the screen is paid (or refunded for paid orders) then we need to change the client. Server can still decide only listen new order events until new want to listen paid order events. |
| 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 |
| 2026-07-30 15:48 | sebasjm | Note Added: 0029310 | |
| 2026-07-30 15:53 | sebasjm | Description Updated | |
| 2026-07-30 15:54 | sebasjm | Assigned To | sebasjm => Florian Dold |
