rodin/review-bot
2
1
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases 6 Wiki Activity

Add structured logging with verbosity levels #23

New Issue
Closed
opened 2026-05-02 03:32:25 +00:00 by rodin · 0 comments
rodin commented 2026-05-02 03:32:25 +00:00
Owner
Copy Link
Copy Source

Problem

The bot currently uses bare log.Printf for all output — warnings, debug info, and status messages are indistinguishable. When something goes wrong (like the token scope issue in PR #22), the CI logs bury the important warning in noise.

Current state

  • All logging via log.Printf / log.Fatalf
  • No way to increase verbosity for debugging
  • No structured fields (e.g., which step failed, what token scope was missing)
  • The update-existing feature silently skips deletion when GetAuthenticatedUser fails — only visible if you grep CI logs for "Warning"

Proposal

  1. Add --log-level / LOG_LEVEL flag (error, warn, info, debug)
  2. Use slog (stdlib, Go 1.21+) for structured logging
  3. Key places that need debug logging:
    • Token identity resolution (who am I?)
    • Review listing (found N reviews, M from self)
    • Delete attempts (deleting review ID X, success/failure)
    • LLM request/response timing
    • Context budget decisions (what got trimmed, how much)
  4. Default level: info (current behavior)
  5. CI workflows should use info by default, debug available for troubleshooting

Context

Discovered in PR #22: the reviewer tokens lacked read:user scope, so GetAuthenticatedUser returned 403. The delete-existing feature silently fell through to posting a new review. This was only visible deep in CI logs as a single warning line. Structured logging with proper levels would make this immediately obvious.

Acceptance criteria

  • Replace log.Printf with slog throughout
  • --log-level flag with env var support
  • Debug-level logging for all Gitea API calls
  • Info-level logging for key workflow steps
  • Warn-level for recoverable failures (like the token scope issue)
  • Error-level for fatal conditions (before exit)
## Problem The bot currently uses bare `log.Printf` for all output — warnings, debug info, and status messages are indistinguishable. When something goes wrong (like the token scope issue in PR #22), the CI logs bury the important warning in noise. ## Current state - All logging via `log.Printf` / `log.Fatalf` - No way to increase verbosity for debugging - No structured fields (e.g., which step failed, what token scope was missing) - The update-existing feature silently skips deletion when `GetAuthenticatedUser` fails — only visible if you grep CI logs for "Warning" ## Proposal 1. Add `--log-level` / `LOG_LEVEL` flag (error, warn, info, debug) 2. Use `slog` (stdlib, Go 1.21+) for structured logging 3. Key places that need debug logging: - Token identity resolution (who am I?) - Review listing (found N reviews, M from self) - Delete attempts (deleting review ID X, success/failure) - LLM request/response timing - Context budget decisions (what got trimmed, how much) 4. Default level: `info` (current behavior) 5. CI workflows should use `info` by default, `debug` available for troubleshooting ## Context Discovered in PR #22: the reviewer tokens lacked `read:user` scope, so `GetAuthenticatedUser` returned 403. The delete-existing feature silently fell through to posting a new review. This was only visible deep in CI logs as a single warning line. Structured logging with proper levels would make this immediately obvious. ## Acceptance criteria - [ ] Replace `log.Printf` with `slog` throughout - [ ] `--log-level` flag with env var support - [ ] Debug-level logging for all Gitea API calls - [ ] Info-level logging for key workflow steps - [ ] Warn-level for recoverable failures (like the token scope issue) - [ ] Error-level for fatal conditions (before exit)
rodin closed this issue 2026-05-02 18:07:13 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ai-review
bug
needs-review
ready
Ready for human review
 self-reviewed
Self-review passed since last push
 wip
Work in progress - do not start new work on this PR
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
security-review-bot rodin (Rodin)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rodin/review-bot#23
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?