View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005903 | Taler | auditor | public | 2019-09-24 07:16 | 2021-09-02 16:14 |
| Reporter | Florian Dold | 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 | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005903: incomprehensible error message "Did not update auditor DB: value existed" | ||||
| Description | This happens on the automated build for taler-test@gv. It probably has something to do with the exchange already being in the database of the auditor. However, it is not clear whether this represents an error condition that must cause the build to fail. | ||||
| Tags | No tags attached. | ||||
| I'm not sure what is incomprehensible about the message, or how to improve it: Somebody is running $ taler-auditor-exchange to *add* an exchange to the list of audited exchanges. That exchange is _already_ in the list of audited exchanges, and since we can have each exchange at most once (UNIQUE constraint), we return this message. The status code is set to "4", in contrast to other errors (1/2/3) that indicate failures for other reasons (failure to connect to DB, etc.). 0 is returned on success. Now, I do agree that this is possibly OK for the buildbot (except maybe the DB should have been *reset* to test everything from scratch, but that's a question of what we intend to do/test/deploy here). So for a build of demo/test, I think it's OK to continue if the status code is 0 or 4, while for an integration test that did reset the DB we should check for 0 only. | |
| Ah. So the solution is to simply check for the respective exit status code I guess. Still, the error message should be improved. I was confused by "value existed". It's not even grammatically correct. What value? Also, some programs write their own name before the error message. Otherwise, there is not enough context to diagnose where the problem even came from. (Just try "cat --foobar" to see an example of this.) How about something like: "taler-auditor-exchange: The exchange '%s' is already audited by this auditor. Refusing to update auditor DB." That's much more user-friendly. | |
| (I'm not saying that we should prefix *all* outputs with the program name, but in this case, it would've added the required context to make the problem easier to diagnose.) | |
| I guess then in this context we should simply switch to GNUNET_log() and log at the ERROR level. That'll give us all the information, and not create yet another special case. | |
| 5e859bae..3b3daa75 fixes the error message by using GNUNET_log () and changing the text a bit. 7d8b8ba..41e0280 documents the return codes of taler-auditor-exchange in docs.git. 3b3daa75..14c7e45e improves the error message in case removal fails. | |
| Fix committed to master branch. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-09-24 07:16 | Florian Dold | New Issue | |
| 2019-09-24 07:16 | Florian Dold | Status | new => assigned |
| 2019-09-24 07:16 | Florian Dold | Assigned To | => Christian Grothoff |
| 2019-09-25 11:14 | Christian Grothoff | Note Added: 0014957 | |
| 2019-09-25 11:15 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2019-09-25 11:26 | Florian Dold | Note Added: 0014958 | |
| 2019-09-25 11:26 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2019-09-25 11:30 | Florian Dold | Note Added: 0014959 | |
| 2019-09-25 11:42 | Florian Dold | Note Edited: 0014958 | |
| 2019-09-25 15:43 | Christian Grothoff | Note Added: 0014963 | |
| 2019-09-26 08:32 | Christian Grothoff | Status | assigned => informing |
| 2019-09-26 08:32 | Christian Grothoff | Resolution | open => fixed |
| 2019-09-26 08:32 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-09-26 08:32 | Christian Grothoff | Note Added: 0014965 | |
| 2019-09-26 08:32 | Christian Grothoff | Product Version | => git (master) |
| 2019-09-26 08:32 | Christian Grothoff | Target Version | => 0.6 |
| 2019-12-20 18:11 | Christian Grothoff | Status | informing => closed |
| 2021-09-02 16:13 | Christian Grothoff | ||
| 2021-09-02 16:14 | Christian Grothoff | Note Added: 0018274 |