Logging sucks

[niteshbalusu11]

This PR is inspired by this excellent article. https://loggingsucks.com/

{"request_id":"...","method":"POST","path":"/v0/register","status_code":200,"duration_ms":45,"user_agent":"Noah/1.2.3 (iOS 17.0; iPhone14,2)","app_version":"1.2.3","network":"signet","public_key":"02abc...","outcome":"success"}

[gemini-code-assist]

Summary of Changes

Hello @niteshbalusu11, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the server's logging infrastructure by introducing a new "Wide Event" system. This system aims to provide a more structured and comprehensive approach to capturing request and event data, replacing the previous ad-hoc tracing macros. The changes centralize logging logic within a new WideEvent module and integrate it across various API endpoints to enrich log entries with specific contextual information, leading to improved observability and easier analysis of application behavior.

Highlights

• New Structured Logging System: Introduced a new WideEvent module and associated WideEventHandle to centralize and standardize logging across the application. This replaces ad-hoc tracing macros with a structured event-based approach.
• Refactored Trace Middleware: The trace_middleware has been completely rewritten to leverage the WideEvent system, enabling richer, more consistent request and response logging, including detailed error handling and performance metrics.
• Contextual Logging in API Endpoints: Various API handlers across app_middleware, gated_api_v0, and public_api_v0 have been updated to integrate with WideEventHandle, allowing them to add specific contextual information (e.g., user keys, transaction IDs, email verification status) to each event.
• Reduced Ad-Hoc Logging: Many direct calls to tracing::debug!, tracing::info!, and tracing::warn! have been removed from API routes, with their functionality now managed by the WideEvent system for better control and less noise.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a significant improvement to logging by implementing a structured 'wide event' pattern. This centralizes request-related context into a single log event, which will greatly improve observability. The implementation is solid, and I have just a few suggestions to further enhance the new logging mechanism's robustness and consistency. My feedback includes handling poisoned mutexes in the logging layer to prevent panics, improving encapsulation of the WideEventHandle, and making a warning log consistent with the new wide event pattern.