After testing and researching some time, I noticed that the current version of the server is quite buggy, especially regarding errors.
For example, the user can currently crash the server simply by sending an ill-formated UUID string. There has also been a case where there was simply no response returned (Which is also sub-optimal)
For these reasons, I think we should focus even more on handling all possible errors and devise tests (with humans at best) to ensure reliable operation (As already discussed during planning)
It might also be a good idea to revise our zero-log policy in a way that we at least store errors that could not be handled (Without any PII so that there aren't as high standards of security to be upheld)
Originally created by @stephan418 on GitHub (Apr 23, 2022).
Original GitHub issue: https://github.com/detleph/server/issues/32
Originally assigned to: @stephan418 on GitHub.
After testing and researching some time, I noticed that the current version of the server is quite buggy, especially regarding errors.
For example, the user can currently crash the server simply by sending an ill-formated UUID string. There has also been a case where there was simply no response returned (Which is also sub-optimal)
For these reasons, I think we should focus even more on handling all possible errors and devise tests (with humans at best) to ensure reliable operation (As already discussed during planning)
It might also be a good idea to revise our zero-log policy in a way that we at least store errors that could not be handled (Without any PII so that there aren't as high standards of security to be upheld)
Request for comments: @Stefan-5422 @Flexla54
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @stephan418 on GitHub (Apr 23, 2022).
Original GitHub issue: https://github.com/detleph/server/issues/32
Originally assigned to: @stephan418 on GitHub.
After testing and researching some time, I noticed that the current version of the server is quite buggy, especially regarding errors.
For example, the user can currently crash the server simply by sending an ill-formated UUID string. There has also been a case where there was simply no response returned (Which is also sub-optimal)
For these reasons, I think we should focus even more on handling all possible errors and devise tests (with humans at best) to ensure reliable operation (As already discussed during planning)
It might also be a good idea to revise our zero-log policy in a way that we at least store errors that could not be handled (Without any PII so that there aren't as high standards of security to be upheld)
Request for comments: @Stefan-5422 @Flexla54
@stephan418 commented on GitHub (May 1, 2022):
This was implemented in #38