View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005565 | Taler | exchange | public | 2019-02-14 12:54 | 2019-12-20 18:12 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | 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 | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005565: exchange cherry picking test fails (again), 8/10 keys returned | ||||
| Description | Feb 14 13:49:46-355822 test-exchange-api-cherry-picking-new-35175 DEBUG Running command `keys-serialization' Feb 14 13:49:46-355826 test-exchange-api-cherry-picking-new-35175 DEBUG Running batched command: check-freshest-keys Feb 14 13:49:46-355830 test-exchange-api-cherry-picking-new-35175 INFO cmd `check-freshest-keys' (ip: 1), key generation: 8 Feb 14 13:49:46-355834 test-exchange-api-cherry-picking-new-35175 ERROR Assertion failed at testing_api_cmd_check_keys.c:141. Feb 14 13:49:46-355839 test-exchange-api-cherry-picking-new-35175 ERROR Got 8 keys in step check-freshest-keys, expected 10 Feb 14 13:49:46-355847 test-exchange-api-cherry-picking-new-35175 ERROR Failed at command `keys-serialization' Feb 14 13:49:46-355852 test-exchange-api-cherry-picking-new-35175 ERROR Batch is at command `check-freshest-keys' | ||||
| Tags | No tags attached. | ||||
| I can't reproduce this either. Try to 'git clean -fdx' in your local copy and then try again. You migth have some ancient key that interferes with the logic.. | |
| I did the git clean -fdx, same result :-( | |
| After careful inspection of the logic, the right answer is that 8 DKs are returned as the first 2 are expired at this point. Not sure why the testcase used to pass (maybe expiration was not properly implemented?), but with 8 DKs the test now passes. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-02-14 12:54 | Christian Grothoff | New Issue | |
| 2019-02-14 12:54 | Christian Grothoff | Status | new => assigned |
| 2019-02-14 12:54 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2019-02-14 12:54 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2019-02-14 12:54 | Christian Grothoff | Status | assigned => implementing |
| 2019-02-14 17:20 | Marcello Stanisci | Note Added: 0013780 | |
| 2019-02-14 20:26 | Christian Grothoff | Note Added: 0013784 | |
| 2019-02-15 13:24 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2019-02-15 13:24 | Christian Grothoff | Status | implementing => informing |
| 2019-02-15 13:24 | Christian Grothoff | Resolution | open => fixed |
| 2019-02-15 13:24 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-02-15 13:24 | Christian Grothoff | Note Added: 0013790 | |
| 2019-12-20 18:12 | Christian Grothoff | Status | informing => closed |