Backup import: improvements - #10920
Conversation
|
🖥️ App preview is ready! 🔗 Preview URL: https://pr-10920.trilium-app.pages.dev ✅ All checks passed This preview will be updated automatically with new commits. |
Bundle ReportChanges will increase total bundle size by 25.28kB (0.02%) ⬆️. This is within the configured threshold ✅ Detailed changes
ℹ️ *Bundle size includes cached data from a previous commit Affected Assets, Files, and Routes:view changes for bundle: client-esmAssets Changed:
view changes for bundle: standalone-esmAssets Changed:
Files in
|
Greptile SummaryThe PR expands backup import and restore support across server, standalone, desktop, and browser clients, including container backups, resumable uploads, setup-mode restoration, and backup downloads.
Confidence Score: 3/5The PR is not yet safe to merge because replacement admission can destroy the active upload before rejecting its successor, and concurrent finish requests can invoke restoration twice. The server still drops an accepted session before checking free space for its replacement, leaving neither upload active when admission fails, while overlapping finish requests still perform the completion lookup outside the session mutex and can repeat the completion callback. Files Needing Attention: apps/server/src/services/chunked_upload.ts
|
| Filename | Overview |
|---|---|
| apps/server/src/services/chunked_upload.ts | Adds upload supersession, process-stamped identifiers, terminal-state caching, and retry-friendly status responses; the previously reported replacement-order and concurrent-finish defects remain. |
| apps/client/src/services/chunked_upload.ts | Extends chunked uploads with request-level retries, online/foreground recovery, resynchronization, cancellation, and reconnecting progress. |
| apps/server/src/services/database_restore.ts | Implements staged database validation, restoration, cleanup, and redacted restore diagnostics. |
| apps/server/src/backup_provider.ts | Extends backup discovery, container generation, download, and path-constrained backup resolution. |
| packages/trilium-backup-container/src/format.ts | Defines the shared backup-container format and validation used across server and standalone targets. |
| apps/client/src/setup.tsx | Integrates backup, existing-data, and restore screens into the setup wizard. |
Sequence Diagram
sequenceDiagram
participant U as User
participant C as Setup client
participant API as Restore API
participant Upload as Chunked upload service
participant Restore as Database restore service
participant DB as SQLite database
U->>C: Select backup
C->>API: Begin restore upload
API->>Upload: Create session
loop Until all bytes arrive
C->>Upload: Send chunk with offset
Upload-->>C: Received-byte status
end
C->>Upload: Finish upload
Upload->>Restore: Hand off staged backup
Restore->>Restore: Validate/decrypt container
Restore->>DB: Replace and initialize database
Restore-->>C: Restore status
Reviews (17): Last reviewed commit: "client/options/backup: add a prompt befo..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const [ oldest ] = sessions.values(); | ||
| remember(oldest.uploadId, { kind: "superseded" }); | ||
| await drop(oldest); |
There was a problem hiding this comment.
When a second restore request cannot satisfy the free-space check, the supersede loop has already deleted the accepted session and its partial file, causing the original upload to receive 410 and the replacement to be rejected without leaving an active upload. How this was verified: The restore route enables supersession, and the admission path drops the current session before requireRoomFor validates the replacement.
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!
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
… straight from the setup screen before restoring a backup
…downloads to avoid quota issues
…at/backup-import-3
…at/backup-import-3
…, where the database can stay locked for changes
2 participants
No description provided.