Update ADR.

Signed-off-by: Munyoki Kilyungi <me@bonfacemunyoki.com>

1 files changed, 3 insertions, 3 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 37fa477..832a946 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
@@ -6,7 +6,7 @@
 
 ## Context
 
-Right now, we have stack-traces embedded in our GN3 error response:
+Currently, GN3 error responses include stack traces:
 
 ```
 def add_trace(exc: Exception, jsonmsg: dict) -> dict:
@@ -44,6 +44,6 @@ Stack traces have the potential to allow malicious actors compromise our system
 
 * Lockstep update in GN2 UI on how we handle GN3 errors.
 
-## Notes
+## Rejection Rationale
 
-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.
+The proposal to remove stack traces from error responses was rejected because they are essential for troubleshooting, especially when issues are difficult to reproduce or production logs are inaccessible.  Stack traces provide immediate error context, and removing them would complicate debugging by requiring additional effort to link logs with specific requests; a trade-off we are not willing to make at the moment.