summaryrefslogtreecommitdiff
path: root/topics
diff options
context:
space:
mode:
authorMunyoki Kilyungi2024-09-17 11:57:15 +0300
committerMunyoki Kilyungi2024-09-17 11:59:45 +0300
commitec83534528ad6053a6d5089b751e3663ff4e7db8 (patch)
tree7643fde93f17a134a850b039445d5dd232a1201d /topics
parentcdc5a05694ff48bc4dae53e6276ca5ed5c7671a8 (diff)
downloadgn-gemtext-ec83534528ad6053a6d5089b751e3663ff4e7db8.tar.gz
Update ADR/gn3/000.
Signed-off-by: Munyoki Kilyungi <me@bonfacemunyoki.com>
Diffstat (limited to 'topics')
-rw-r--r--topics/ADR/gn3/000-remove-stace-traces-in-gn3-error-response.gmi4
1 files changed, 4 insertions, 0 deletions
diff --git a/topics/ADR/gn3/000-remove-stace-traces-in-gn3-error-response.gmi b/topics/ADR/gn3/000-remove-stace-traces-in-gn3-error-response.gmi
index 7c0c7d6..37fa477 100644
--- a/topics/ADR/gn3/000-remove-stace-traces-in-gn3-error-response.gmi
+++ b/topics/ADR/gn3/000-remove-stace-traces-in-gn3-error-response.gmi
@@ -43,3 +43,7 @@ Stack traces have the potential to allow malicious actors compromise our system
## Consequences
* Lockstep update in GN2 UI on how we handle GN3 errors.
+
+## Notes
+
+ADR rejected. Currently, having stack traces are a convenient feature for situations where bugs are being reported to us by others. It's not always easy to reproduce the issue in question and check logs (since they wouldn't show up in production and would need to de reproduced locally); therefore having stack traces available in such situations can be very useful. To also get rid of the stack traces, then we'd have to link each trace in the logs with the request that caused it, so during troubleshooting, we can correlate and endpoint to an error and it's trace.