View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007750 | Taler | exchange | public | 2023-03-07 17:18 | 2023-09-23 13:09 |
| Reporter | MS | Assigned To | MS | 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 | have not tried |
| Status | closed | Resolution | no change required | ||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0007750: taler-exchange-wirewatch ignores the -f option | ||||
| Description | That causes requests to Nexus /history/incoming to lack the long_poll_ms parameter. | ||||
| Tags | No tags attached. | ||||
| I've inspected the code (visually), and it seems to CLEARLY set the timeout, except for two key cases: 1) if we are in test-mode (-t), and 2) if we are going backwards in time In both cases, using the timeout makes no sense and is correctly disabled. How exactly are you calling taler-exchange-wirewatch to conclude that '-f' is not respected? | |
| with -t. Why is that disabled? What if users want to check that both client and server respect the timeout? | |
| -t is test-mode, where the service is supposed to exit when no more work is available, not "hang around". So long polling doesn't make sense in test-mode. | |
| Also, the help message is unclear about the unit of time being expected by -f. Below is the relevant --help part: -f, --longpoll-timeout=DELAY what is the timeout when asking the bank about new transactions After some tries, it seems that -f N translates to a long_poll_ms of N/1000. This command: $ taler-exchange-wirewatch -c wirewatch.conf -L DEBUG -f 100000 Causes this request: GET /facades/test-facade/taler-wire-gateway/history/incoming?delta=1024&long_poll_ms=100 Is that intentional? | |
| Yes. Note that you probably want to use $ taler-exchange-wirewatch -c wirewatch.conf -L DEBUG -f "100 ms" $ taler-exchange-wirewatch -c wirewatch.conf -L DEBUG -f "30 s" etc, just like we usually do when passing time values. Without any unit, it is microseconds and hence correctly divided by 1000. | |
| Ack. for the clarification and yes, without "-t" wirewatch sends the long_poll_ms parameter. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-03-07 17:18 | MS | New Issue | |
| 2023-03-07 17:18 | MS | Status | new => assigned |
| 2023-03-07 17:18 | MS | Assigned To | => Christian Grothoff |
| 2023-03-07 17:18 | MS | Priority | normal => high |
| 2023-03-07 20:20 | Christian Grothoff | Note Added: 0019927 | |
| 2023-03-07 20:20 | Christian Grothoff | Assigned To | Christian Grothoff => MS |
| 2023-03-07 20:20 | Christian Grothoff | Status | assigned => feedback |
| 2023-03-08 13:27 | MS | Note Added: 0019934 | |
| 2023-03-08 13:29 | Christian Grothoff | Note Added: 0019935 | |
| 2023-03-08 13:39 | MS | Note Added: 0019936 | |
| 2023-03-08 13:49 | Christian Grothoff | Note Added: 0019937 | |
| 2023-03-08 13:50 | Christian Grothoff | Note Edited: 0019937 | |
| 2023-04-04 13:58 | Florian Dold | Target Version | => 0.9.3 |
| 2023-04-11 17:15 | MS | Note Added: 0020075 | |
| 2023-04-11 17:16 | MS | Status | feedback => informing |
| 2023-04-11 17:16 | MS | Resolution | open => no change required |
| 2023-09-23 13:07 | Christian Grothoff | Fixed in Version | => 0.9.3 |
| 2023-09-23 13:09 | Christian Grothoff | Status | informing => closed |