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
Add --log-level / LOG_LEVEL flag (error, warn, info, debug)
Use slog (stdlib, Go 1.21+) for structured logging
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)
Default level: info (current behavior)
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)
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.
Problem
The bot currently uses bare
log.Printffor 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
log.Printf/log.FatalfGetAuthenticatedUserfails — only visible if you grep CI logs for "Warning"Proposal
--log-level/LOG_LEVELflag (error, warn, info, debug)slog(stdlib, Go 1.21+) for structured logginginfo(current behavior)infoby default,debugavailable for troubleshootingContext
Discovered in PR #22: the reviewer tokens lacked
read:userscope, soGetAuthenticatedUserreturned 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
log.Printfwithslogthroughout--log-levelflag with env var support