Conversation
Greptile SummaryThis PR separates the previously unified "usage statistics" backup option into two independent flags:
Confidence Score: 3/5Safe to merge for first-time restores; re-restoring the same backup with IncludeUsageStats=true and IncludeRequestLogs=false will silently accumulate duplicate usage log rows on each run. The backup direction and all wiring (GraphQL, frontend, auto-backup) are clean and correct. The restore direction introduces ensureUsageLogRequests, which skips the fingerprint-based deduplication that restoreUsageRequests uses, so every invocation inserts fresh stub rows regardless of what is already in the database. Users who restore the same file more than once, or who restore in two steps, will end up with multiplied usage log entries. The restore path also has zero new test coverage despite being the more complex half of the change. internal/server/backup/restore.go — the new ensureUsageLogRequests function needs a deduplication mechanism; internal/server/backup/backup_test.go — restore scenarios for the new flags are missing Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Restore called] --> B{IncludeUsageStats\nOR IncludeRequestLogs?}
B -- No --> Z[Skip usage data]
B -- Yes --> C[restoreUsageData]
C --> D{IncludeRequestLogs?}
D -- Yes --> E[restoreUsageRequests\ncheck existing by ID + fingerprint\npopulate requestIDMap]
D -- No --> F[requestIDMap = empty]
E --> G{IncludeUsageStats?}
F --> G
G -- No --> Z2[return nil]
G -- Yes --> H[restoreUsageLogs]
H --> I[ensureUsageLogRequests\ncreate shell Request rows\nfor unmapped usage logs\nNO dedup vs DB]
I --> J[build requestIDs from map]
J --> K[query existingLogRequestIDs for dedup]
K --> L[insert UsageLog rows\nskip if already exists]
|
Uh oh!
There was an error while loading. Please reload this page.