blob: 45fe6cfcae9f28d8e2adf37e6375e681a0ad9b0d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
# Bug Triage & Resolution Guide
This reference provides a structured approach to managing production bugs using the `doot` project's custom scripts.
## 1. Listing Bugs
Use `./scripts/bugs` to list all currently open bugs from the production database.
Bugs are stored in the `bugs` table with `id`, `description`, and `created_at`.
## 2. Investigating Logs
When a bug is reported, always check the production logs first.
Use `./scripts/logs` with various flags:
- `scripts/logs -n 200`: View the last 200 lines.
- `scripts/logs --since "1 hour ago"`: View recent logs.
- `scripts/logs --grep "error"`: Search for specific error patterns.
- `scripts/logs -f`: Follow logs in real-time (useful for reproduction).
### Common Error Patterns
- **Database Locked:** SQLite `database is locked` errors usually indicate concurrent writes or long-running transactions.
- **Unauthorized:** Check for `401` or `403` status codes in API clients (Todoist, Trello, etc.).
- **Template Errors:** Look for `template: ...: executing ...: nil pointer evaluating ...` which indicates missing data in the renderer.
## 3. Reproduction
Before applying a fix, attempt to reproduce the bug locally.
1. Use `go test ./...` to ensure the current state is stable.
2. Create a new test case in the relevant `*_test.go` file that specifically triggers the reported bug.
3. Confirm the test fails.
## 4. Resolution
Once a fix is implemented and verified locally:
1. Deploy the fix using `./scripts/deploy`.
2. Verify the fix in production if possible (e.g., by checking logs).
3. Use `./scripts/resolve-bug <id>` to mark the bug as resolved in the production database.
## 5. Verification
After resolving, run `./scripts/bugs` again to ensure it no longer appears in the list.
Update `SESSION_STATE.md` to reflect the completed bug fix.
|
