Closed BLuedtke closed 7 months ago
This concludes the changes I wanted to make before testing.
Known mistakes:
Tested the correctness of the logs for all endpoints except for monitor
/pure getters.
log2.txt
log2-clientside.txt
For pure getters, i.e. those handlers that only log on the level LOG_NOTICE
, I tested that they respond as expected, but I did not check the correctness of their logs (not enough time).
The previous commit resulted from this testing.
For human-readability, I think it is necessary to add
- start
because it's very hard to remember the message format to look for until you reach the message with- finish
(then you can backtrack to the corresponding "start" message.
I agree. Also: Should it be "finish" instead of "finished"?
Somewhat related: Should the error messages after - start
, that also indicate end of processing, have something like - abort
? It'd clarify that it's the end of processing at the cost of (probably) more line breaks. On the other hand, an error log at the end of processing is not really "aborting", so not sure if that term is suitable.
The ci is failing due to some build setup issue, specifically when trying to install libgnutls
. Will also have to look at that at some point.
Pipeline works again, added apt update before any step where apt packages are installed.
In the long term (regarding the ci pipeline), we may also want to switch from ubuntu-latest
to a fixed ubuntu version (currently ubuntu-latest
seems to be Jammy/22.04).
For the code documentation, think about whether libbidib's doxygen setup could be reused.
I'd cover that in a future issue/pr, not in this one
https://github.com/uniba-swt/swtbahn-cli/pull/127#discussion_r1411955058 somehow I cannot answer to that comment/change request. Not sure why. I'm adjusting the message in a way similar to the proposed message.
Alright, the "Improve Logging" branch has grown to incorporate a bit more than just logging improvements.
The biggest changes are in the request handlers. I moved the validation around such that they follow a pattern:
The "log request start" is also outfitted with data about request parameters, such that one can trace after the fact what request is which, if there are multiple trains/users active. Furthermore, the "log request finished" is the exact same as the "log request start" if possible, just with a "finished" at the end. This makes it relatively easy to trace when a request came in and when it was finished.
Since I already had to touch most of the handlers and some related functions, I made some adjustments to them, mostly regarding validation and formatting. There are also some notes I made on areas of the codebase that may need some change but where we should really discuss it first.
This is a bit of a bigger change, but IMO prepares us to tackle the API rework.