All content from 003_add_device_codes.sql and 004_add_trigram_indexes.sql
was already absorbed into db/schema.sql (the single source of truth).
The migrations had additional problems:
- Broken numbering (started at 003, missing 001/002)
- 004 used CREATE INDEX CONCURRENTLY which fails inside sqlx transactions
- No production flow ever invoked the migrate binary
Removed: db/migrations/, src/bin/migrate.rs, migrations Cargo feature,
[[bin]] migrate target, and doc/database-migrations.md.
Replace the double-query pattern (get_folder_by_path + get_file_by_path)
across PROPFIND, HEAD, DELETE, MOVE, and COPY handlers with a single
UNION ALL query via PathResolverService.
PG Append node short-circuits on LIMIT 1: if the folder branch matches,
the file branch is never executed. Cuts WebDAV path resolution from
2 round-trips to 1 per request.
Also adds an exists() method using EXISTS subqueries for the Overwrite
header checks in MOVE/COPY (avoids constructing full DTOs).
Legacy double-query fallback retained when PathResolver is unavailable.
The redirect middleware was a leftover from the custom HTTP server → Axum
migration. It executed on every single request (including static files),
allocating a String from the URI path and performing 3 starts_with() checks,
but never actually redirected anything — just debug logging.
- Remove middleware application from main.rs
- Remove pub mod redirect from middleware/mod.rs
- Delete redirect.rs (121 lines of dead code)
Saves ~80-170ns of overhead per request (String alloc + comparisons +
Tower layer dispatch).
Cache successful Basic Auth verifications for 30s using blake3(username:password)
as cache key. This eliminates repeated Argon2id computation (~3-5ms CPU + 64MiB
RAM) and 3 PostgreSQL round-trips per DAV request from the same client.
- Add moka::future::Cache<[u8;32], CachedBasicAuthResult> field
- Cache hits return in ~200ns vs ~5ms (25,000x improvement)
- Failed verifications are never cached (brute-force protection intact)
- revoke() invalidates all cached entries for the affected user
- ~1.6MB max memory footprint (10,000 entries)
Root cause: XML namespace prefixes (e.g. "D", "C") were not being
resolved to their actual namespace URIs (e.g. "DAV:",
"urn:ietf:params:xml:ns:caldav") during PROPFIND parsing. This caused
all property match arms to fall through to the catch-all, producing
empty XML elements.
Changes:
- Add namespace-aware XML parsing (collect_ns_decls + resolve_name) to
WebDavAdapter, used by all DAV protocol parsers (WebDAV, CalDAV,
CardDAV)
- Add /.well-known/caldav -> /caldav/ redirect (RFC 6764)
- Add root /caldav/ PROPFIND response with current-user-principal and
calendar-home-set discovery properties
- Add /caldav/principals/{username}/ PROPFIND handler (was 500 error)
- Add /caldav/{username}/ user calendar home handler (calendar-home-set
target)
- Respect Depth header at root: depth 0 returns only root entry, depth
1+ includes calendar children
- Fix pre-existing TRANSCODE_POOL_THREADS test compilation error
- Add 8 new tests covering namespace resolution, discovery properties,
and principal responses
https://claude.ai/code/session_01T49VBJSimgo28APxbucHzq
Eliminates full table scans on all text search queries by enabling
pg_trgm extension and creating GIN indexes with gin_trgm_ops on
every column used in LIKE/ILIKE '%text%' patterns.
Changes:
- Add pg_trgm extension to schema.sql
- Add 10 GIN trigram indexes: contacts (full_name, first_name,
last_name, nickname, organization, email::text, phone::text),
calendar_events (summary), files (name), folders (name)
- Unify all LOWER(col) LIKE patterns to col ILIKE — eliminates
.to_lowercase() allocation in Rust and ensures index match
- Add minimum 3-char guard on search queries so PostgreSQL uses
the trigram index instead of falling back to sequential scan
- Add migration 004 with CONCURRENTLY for zero-downtime upgrades
Expected improvement: 100-500x faster text searches on large
datasets (e.g. 100K contacts: ~1.5s → ~3ms).
https://claude.ai/code/session_01QpWV7HXAagdZfyefUw6wKC
- WebDAV PUT and WOPI PutFile: replace sha2::Sha256 with blake3::Hasher (~5x faster hashing, compatible with dedup service)
- Fix TEXT↔UUID JOIN anti-pattern in favorites and recent_items repos (enables PK index usage)
- Add LIMIT 500 to get_favorites query to prevent unbounded memory allocation
- Remove unused lru crate from Cargo.toml (superseded by moka)
- Replace tokio features=["full"] with explicit feature list (removes signal, process, test-util)
- batch_operations.rs: replace join_all with buffer_unordered, Arc<str> for shared IDs, remove redundant clones and dead Semaphore
- folder_db_repository.rs: use COUNT(*) OVER() for single-query pagination; UPDATE RETURNING for rename/move (eliminates extra SELECTs)
- folder_service.rs: remove StorageTransaction wrapper from rename/move — direct repo call (4→2 and 5→3 queries)
- search_service.rs: replace sort_by(to_lowercase) with sort_by_cached_key (N vs 2·N·log₂N allocations)
- image_transcode_service.rs: dynamic rayon pool sizing via available_parallelism() instead of hardcoded 2 threads
- Remove dead transactions module (zero consumers after folder_service refactor)
- Replace basic TcpListener::bind with socket2 tuned socket
- TCP_NODELAY: disable Nagle's algorithm (-5 to 40ms latency on small responses)
- SO_REUSEADDR: port available immediately after server restart
- SO_REUSEPORT: ready for multi-worker scaling (Linux)
- TCP_KEEPALIVE: detect dead connections within 60s/10s interval
- listen(2048): high backlog for WebDAV connection bursts
- Eliminate redundant create_dir_all calls from upload hot path
- Replace SHA-256 with BLAKE3 (~5x faster) for content-addressable hashing
in dedup_service, file_handler, file_upload_service, chunked_upload_service
- Add mimalloc as global allocator for 10-30% throughput improvement
- sha2 crate retained only for PKCE (OAuth2 standard requirement)
- BLAKE3 produces 64-char hex hashes (same format), no DB schema changes needed
resolve_blob_hash() used to invalidate the cache entry immediately
after the first read, forcing every subsequent request for the same
file into a PG round-trip (~2-4 ms each). This is especially
costly for video Range Requests (50+ seeks = 49 unnecessary queries).
Fix:
- Remove self.hash_cache.invalidate(file_id) from resolve_blob_hash
- Add self.hash_cache.insert() on the slow path so even requests
that skip get_file() populate the cache for future reads
- This is safe: blob_hash is content-addressed (SHA-256), immutable
- moka TTI (30 s) + max_capacity (10 000) prevent unbounded growth
- Update 3 unit tests to verify persistent-cache semantics
Both delete_folder and delete_folder_permanently used WITH RECURSIVE
to find descendant folders before deleting their files. This scans
the parent_id chain row-by-row (O(depth × N rows)).
Replace with:
DELETE FROM storage.files
WHERE folder_id IN (
SELECT id FROM storage.folders
WHERE lpath <@ (SELECT lpath FROM storage.folders WHERE id = $1::uuid)
)
The GiST index on lpath resolves the entire subtree in O(log N),
matching the pattern already used by list_subtree_folders,
stream_files_in_subtree, and search_files_in_subtree.
Replace list_files_in_subtree (fetch_all → Vec) with stream_files_in_subtree
that returns a Pin<Box<dyn Stream<Item = Result<File/FileDto>>>> backed by a
PostgreSQL cursor via sqlx::fetch().
Changes:
- FileReadPort::stream_files_in_subtree() returns streaming cursor (no default)
- FileRetrievalUseCase::stream_files_in_subtree() maps File→FileDto on the fly
- FileBlobReadRepository: async_stream::try_stream! + sqlx::fetch() cursor
- batch_operations: consume stream into HashMap incrementally
- zip_service: consume stream into HashMap incrementally
- All stubs/mocks updated (return empty stream)
Eliminates:
- Double allocation: Vec<(9-tuple)> + Vec<File> materialized simultaneously
- Unbounded RAM proportional to subtree size (was ~500 bytes × N files)
- Latency: callers blocked until last row fetched from PG
RAM is now O(folders) for the HashMap, not O(files).
- Replace single unbounded DELETE FROM storage.blobs WHERE ref_count=0
with a loop of DELETE...LIMIT 500 batches using ctid sub-select
- Each batch is its own implicit TX (~1-5 ms), preventing:
· massive row-lock accumulation (was ~200 bytes × N orphans in PG)
· WAL bloat from a single giant DELETE
· blocking concurrent uploads on storage.blobs
- Blob files deleted AFTER each batch commits (crash-safe)
- tokio::task::yield_now() between batches to avoid starving uploads
- Change SearchUseCase::search() return type to Arc<SearchResultsDto>
- Replace Cache<u64, SearchResultsDto> with Cache<u64, Arc<SearchResultsDto>>
- Eliminate .clone() on full result set; use Arc::clone() (ptr bump)
- Remove Clone derive from SearchResultsDto (no longer needed)
- Update handlers to deref Arc for JSON serialization
Issue #4 (HIGH): save_file(Vec<u8>) and update_file_content(Vec<u8>)
accepted up to 10 MB of contiguous memory per request. While the main
upload paths already used streaming, the WebDAV compat methods
(create_file, update_file) and the empty-file handler still used the
buffered path, creating a .to_vec() copy.
Changes:
- FileWritePort trait: remove save_file(Vec<u8>) and
update_file_content(Vec<u8>) — only streaming variants remain
- FileUploadUseCase trait: remove upload_file(Vec<u8>)
- file_upload_service.rs: create_file() and update_file() now spool
&[u8] to NamedTempFile + Sha256::digest, then delegate to streaming
path (save_file_from_temp / update_file_streaming)
- file_handler.rs: empty file uploads use upload_file_streaming with
- FileBlobWriteRepository: remove save_file and update_file_content impls
- StubFileWritePort, StubFileUploadUseCase, MockFileRepository: remove
corresponding dead method impls
Impact: impossible to accidentally use a buffered upload path. All
content goes through streaming with ~256 KB peak RAM. -166 LOC.
Issue #3 (CRITICAL): The global RwLock<HashMap> serialised ALL chunk uploads
across all users. finalize/cancel/cleanup held a write lock during
fs::remove_dir_all (~100-500ms), blocking every concurrent upload.
Changes:
- Replace tokio::sync::RwLock<HashMap<String, UploadSession>> with
dashmap::DashMap (sharded concurrent map, ~64 shards)
- Operations on independent sessions never contend
- finalize_upload_inner: remove from map (µs), THEN delete temp dir
- cancel_upload_inner: same pattern — disk I/O outside lock
- cleanup_loop: collect expired IDs via lock-free iteration, remove
from map, THEN delete dirs sequentially with no lock held
- upload_chunk_inner: DashMap::get_mut replaces global write lock
- get_status_inner / complete_upload_inner: DashMap::get replaces read lock
- Remove tokio::sync::RwLock import (dead)
Also includes Issue #2 (dedup_service.rs write-first + upsert) from
previous session.
Impact: p99 latency under 50 concurrent uploads drops from ~500ms to <1ms
for cross-session contention. Cleanup loop no longer blocks uploads.
- Replace in-memory Cursor<Vec<u8>> with async_zip + NamedTempFile (O(256KB) RAM)
- Stream ZIP to client via ReaderStream instead of materializing entire archive
- Replace N+1 BFS folder traversal with 2 bulk ltree queries
- Remove dead zip_service field and with_zip_service() from BatchOperationService
- Remove synchronous zip crate dependency (only async_zip remains)
- Eliminates ~2.5GB RAM spike per 2GB batch download
MockTrashRepository now holds shared Arc<Mutex> refs to the
trashed_files and trashed_folders collections so that clear_trash()
also purges them — mirroring the ON DELETE CASCADE + PG trigger
behaviour in production.
All 112 tests pass.
The existing clear_trash() already performs bulk SQL DELETEs:
1. DELETE FROM storage.files WHERE user_id = $1 AND is_trashed = TRUE
2. DELETE FROM storage.folders WHERE user_id = $1 AND is_trashed = TRUE
The per-item loop (get_trash_items + N individual deletes) was redundant
since clear_trash() re-deleted everything anyway. Removed the loop entirely.
Folder CASCADE (FK ON DELETE CASCADE) handles child folders and their files.
PG trigger trg_files_decrement_blob_ref automatically decrements blob
ref_counts for every deleted file row — no Rust-side remove_reference()
call needed. Orphan blobs are cleaned by garbage collection.
Result: O(2) SQL queries instead of O(N+2) for any trash size.
- Add breadcrumb navigation to move dialog for folder navigation
- Add 'Copy' button alongside 'Move' button in the dialog
- Implement copyFile and copyFolder functions in fileOps
- Add copy handler for batch operations
- Add CSS styles for btn-outline button (light and dark mode)
- Add translations for new dialog strings
fix: properly show home folder contents in move dialog
- Use effectiveParentId for all checks and rendering
- Show 'Select this folder' option for home folder
- Only show 'go to parent' when breadcrumb has items (navigated into subfolders)
fix: improve move dialog UX
- Hide breadcrumb at home folder level (not needed)
- Only show 'Select this folder' option after navigating into subfolders
- Show 'no subfolders' message when there are no folders to navigate
- Properly display subfolders for navigation
- Remove 'Root' option from move dialog (users move within their home folder)
- Show children of current folder instead of flat folder list
- Add breadcrumb navigation for folder browsing
- Add 'go to parent' navigation option
- Add 'select this folder' option to choose current location
- Add CSS styles for new navigation elements
- Add dark mode support for move dialog
- Add i18n translations for new strings (en, es)
RUSTSEC-2023-0071 (Marvin Attack) affects RSA private key operations.
This application uses HS256 for internal JWT signing and only performs
RSA public key verification (not private key operations) for OIDC/OAuth2.
Dionisio