View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008110 | Taler | exchange | public | 2024-01-18 16:18 | 2025-04-17 22:28 |
| Reporter | fefe | Assigned To | 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 | feature | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Target Version | post-2.0 | ||||
| Summary | 0008110: feature request: library functions should not abort the process | ||||
| Description | The Taler code is based on Gnunet, which will wrap memory allocations to abort the process if they fail. It also uses Gnunet assertions which will abort the process if a condition is not met. This can be argued to produce less complex and therefore more readable code if you write code for an application, but I think we should reopen the discussion for code you ship as a library for others to use. Many library users will find it not acceptable if their GUI application just crashes after the response from the exchange triggered some internal inconsistency check assertion. Library code should never crash the application, not unintentionally and also not intentionally. Logic bugs like refcount overflows should be detected and handled, but not through crashing the application. The library should return an error instead and make sure not to leak ressources in the error path. The calling application should get the opportunity to display a nice error message instead of just crashing. | ||||
| Tags | No tags attached. | ||||
| I still disagree, handling these super-insane errors (like out-of-memory, or RC exceeds 4 billion) would also for the applications using this likely not be an adequately tested path. *Our* memory consumption is also rather tiny (for any GUI), so *we* are unlikely to blame, and most GUIs I know will also not survive out-of-memory situations. The actual main user of the library are again Taler services that are single-threaded and auto-restarted and in fact periodically auto-killed by systemd, so they _expect_ this behavior, too. Again, for simplicity in their design to avoid too complex error handling. I'm happy to *document* this limitation (or feature), but not exactly seeing that you could change my mind here. | |
| Added comment in header that the library is expected to be used-single threaded and may abort() on out-of-memory situations. To clarify: this is a *reference* implementation showcasing _how_ one would interact with the REST API that is also used by a single-threaded auto-restarted merchant backend. It is not expected to be used 'everywhere', we have re-implementations in TypeScript and PHP for some of the functions, and I fully expect more language bindings in the future. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-18 16:18 | fefe | New Issue | |
| 2024-01-18 16:18 | fefe | Status | new => assigned |
| 2024-01-18 16:18 | fefe | Assigned To | => Christian Grothoff |
| 2024-01-18 21:31 | Christian Grothoff | Note Added: 0020911 | |
| 2024-01-18 21:31 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-01-18 21:31 | Christian Grothoff | Status | assigned => feedback |
| 2024-01-18 22:31 | Christian Grothoff | Relationship added | child of 0008112 |
| 2024-01-23 17:39 | Christian Grothoff | Target Version | => post-1.0 |
| 2024-01-23 17:53 | Christian Grothoff | Note Added: 0020998 | |
| 2024-01-23 17:55 | Christian Grothoff | Severity | minor => feature |
| 2024-08-12 08:11 | Christian Grothoff | Target Version | post-1.0 => post-2.0 |
| 2025-04-17 22:28 | Christian Grothoff | Assigned To | Florian Dold => |
| 2025-04-17 22:28 | Christian Grothoff | Status | feedback => acknowledged |