fix(upload-folder): explain which folders collided instead of a generic bailout#20
Merged
Merged
Conversation
…ic bailout When a local folder's top-level name collided with an existing remote folder, create_folder_with_retry (internxt-core) returned None, and upload_folder silently swallowed it — every child needing that folder as a parent was skipped with only a "Parent folder not found" message, and if the tree had a single top-level folder, folder_map ended up empty, tripping "Failed to create folders, cannot upload files" with no indication of what actually happened or which folder was at fault. Now: report exactly which folder(s) hit a name collision (and their contents get skipped) as they're discovered, thread real create errors through with folder-name/path context instead of a bare unlabeled propagation, and have the final bailout message name the colliding folder(s) plus actionable next steps. The real fix — making create_folder_with_retry look up and return the existing folder's uuid on this conflict, so a collision doesn't need to skip anything at all — belongs in internxt-core; see Bebbssos/internxt-core-rust#4 (unreleased at the time of writing). Once that lands and the dependency here is bumped, the all-or-nothing folder_map.is_empty() bailout can likely be relaxed to skip only the affected subtree, matching the per-file partial-failure reporting used further down in this function. Left a code comment to that effect. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… bailout internxt-core 0.1.2 (released, includes PR #4) makes create_folder_with_retry look up and return the existing folder's uuid on a name collision instead of giving up, so the common case is now fully transparent: a colliding folder (and its contents) upload normally instead of being skipped. Ok(None) is now only the rarer case (lookup miss on a race, or exhausted non-conflict retries) — treat it the same as any other per-item failure: track it in the shared `failed` list (moved up so both the folder and file loops share it) and skip just that subtree, instead of aborting the whole upload via the old `folder_map.is_empty()` bailout (removed). A missing parent (because its own folder failed) is now also tracked in `failed` rather than just a status line, so it's no longer invisible in the final summary/exit code either. Live-verified: re-uploading an identical tree (folder-name collision on every level) now succeeds at the folder level ("Folder ready: x" for all three, no skipping) and only the genuinely-conflicting files fail with a clear 409 each — exactly the behavior the original bug report wanted, instead of the old unconditional "Failed to create folders, cannot upload files" abort. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bebbssos
force-pushed
the
fix/upload-folder-name-collision-message
branch
from
July 22, 2026 16:21
3860160 to
cc9a9e6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
ixr upload folderon a local directory tree whose top-level folder namecollides with an already-existing remote folder aborted the ENTIRE upload
with a misleading, unhelpful error, silently dropping every file/subfolder
that needed that colliding folder as a parent — even brand-new content
nested underneath that had nothing to do with the collision.
Root cause:
internxt-core'screate_folder_with_retryreturnedOk(None)on an "already exists" conflict without ever looking up theexisting folder's uuid, so the CLI had no way to continue treating it as
"found the existing folder" — it could only skip.
Fix (now complete, two repos)
1.
internxt-core-rust(separate repo/crate this depends on):PR #4, merged and
released as 0.1.2. On "already exists,"
create_folder_with_retrynowlooks up and returns the existing folder's uuid (paginating
get_folder_subfolders, matching by exact name) instead of giving up.Ok(None)is now reserved for the rarer case where even that lookup fails(a race) or non-conflict retries are exhausted.
2. This repo (now bumped to
internxt-core = "0.1.2"):upload_folderin
src/commands.rsfully reworked around the new behavior:(and everything nested under it) uploads normally, logged as
Folder ready: Xrather than a skip.failedtracker (previously file-only) is now populated byfolder-level problems too: a genuine
Ok(None)(lookup-miss race /exhausted retries), an unretryable
create_folder_with_retryerror, and a"parent folder not found because its own creation failed" skip. All three
used to be either a silent status line or a hard
return Errabortingeverything; now they're tracked per-item and reported in the final
summary/exit code alongside file failures, and only the affected subtree
is skipped.
folder_map.is_empty()all-or-nothing bailout entirely —no longer needed, since a genuinely total failure now naturally surfaces
through the same per-item
failedreporting as everything else.Test plan
cargo build --all-features/cargo test --all-features(32/32) /cargo clippy --workspace --all-targets --all-features— clean, samepre-existing warnings only, none new
3-folder/3-file tree, then uploaded the identical tree again to
reproduce the original collision. Now:
Folder ready: Xfor allthree folders (no skip, no abort), and only the 3 genuinely-duplicate
files fail, each with a clear
409 Conflictreason and exit code 1 —exactly the behavior the bug report wanted, replacing the old
unconditional "Failed to create folders, cannot upload files".
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com