Skip to content

opt: backup/restore usages logs seprated, close #1712#1766

Merged
looplj merged 1 commit into
unstablefrom
dev-tmp
Jun 3, 2026
Merged

opt: backup/restore usages logs seprated, close #1712#1766
looplj merged 1 commit into
unstablefrom
dev-tmp

Conversation

@looplj

@looplj looplj commented Jun 2, 2026

Copy link
Copy Markdown
Owner

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.

Open in Devin Review

@greptile-apps

greptile-apps Bot commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR separates the previously unified "usage statistics" backup option into two independent flags: IncludeUsageStats (aggregated token/cost logs) and IncludeRequestLogs (raw HTTP request/response bodies). The version is bumped from 1.2 → 1.3, old format backups remain restorable, and a new ensureUsageLogRequests helper creates lightweight stub Request rows when restoring usage stats without their associated request logs.

  • Backup path (backup_ops.go): cleanly split — usage requests fetched only when IncludeRequestLogs, usage logs only when IncludeUsageStats; both use compact JSON marshalling when either flag is active.
  • Restore path (restore.go): restoreUsageStats replaced by restoreUsageData; new ensureUsageLogRequests creates stub requests for usage logs whose originating requests were not restored — but unlike restoreUsageRequests, these stubs have no deduplication check against the database, so a second restore of the same backup will create duplicate stubs and duplicate usage log rows.
  • Frontend / GraphQL: new toggle added consistently across manual backup, restore, and auto-backup panels; GQL schema and generated resolver code updated correctly.

Confidence Score: 3/5

Safe 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

Filename Overview
internal/server/backup/restore.go Split restoreUsageStats into restoreUsageData with separate request-log and usage-stats paths; added ensureUsageLogRequests to create stub Request rows when restoring stats without logs — but stubs are not deduplicated against existing rows, breaking re-restore idempotency
internal/server/backup/backup_ops.go Backup logic cleanly separated: UsageRequests collected only when IncludeRequestLogs, UsageLogs only when IncludeUsageStats; both paths use compact JSON marshalling when either flag is set
internal/server/backup/backup_test.go Existing WithUsageStats test updated to expect zero UsageRequests; new WithRequestLogs test added covering backup direction; restore path for new flags has no test coverage
internal/server/backup/types.go BackupVersion bumped to 1.3, old 1.2 aliased as BackupVersionV3; IncludeRequestLogs field added to BackupOptions and RestoreOptions
frontend/src/features/system/components/backup-settings.tsx New includeRequestLogs toggle added to manual backup, restore, and auto-backup settings panels; defaults to false in all three initial state objects

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]
Loading

Comments Outside Diff (2)

  1. internal/server/backup/restore.go, line 1281-1432 (link)

    P1 ensureUsageLogRequests has no dedup — each restore creates duplicate shell requests

    When restoring with IncludeUsageStats=true, IncludeRequestLogs=false, this function creates a stub Request row for every usage log whose original request ID is not in requestIDMap. It does so unconditionally, with no check against the database.

    Unlike restoreUsageRequests, which calls existingUsageRequests to look up both by original backup ID and by a content fingerprint before inserting, ensureUsageLogRequests always writes. On a second restore of the same backup (e.g., after a migration or accidental double-run), it creates new shell request rows for every usage log, and the downstream existingLogRequestIDs check in restoreUsageLogs queries against the freshly created shell IDs rather than the IDs created on the first run, so the duplicate usage logs pass the guard and are inserted.

  2. internal/server/backup/backup_test.go, line 365-405 (link)

    P2 No test coverage for the new restore path

    The PR adds thorough tests for the backup direction (both WithUsageStats and WithRequestLogs), but there are no tests at all for Restore with the new options. In particular, ensureUsageLogRequests — the most complex new function — is completely untested. Scenarios worth covering include: restore with IncludeUsageStats=true, IncludeRequestLogs=false (shell requests created), restore with both flags true (shells skipped, real requests used), and idempotent re-restore of the same file.

    Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Reviews (1): Last reviewed commit: "opt: backup/restore usages logs seprated..." | Re-trigger Greptile

@looplj looplj merged commit be5523c into unstable Jun 3, 2026
4 checks passed
junjiangao pushed a commit to junjiangao/axonhub that referenced this pull request Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant