apt2aptly: use dist-scoped, directory-safe upload directory

[Copilot]

Concurrent apt2aptly runs all uploaded to /api/files/apt2aptly, causing files from different distributions to collide and land in the wrong repos.

Changes

• apt2aptly/src/main.rs: Replace the hardcoded "apt2aptly" upload directory with a per-distribution name derived from base_dist(), sanitized to be directory-safe (non-alphanumeric chars except -/_ replaced with -).

// Before
actions.apply("apt2aptly", &upload_opts).await?;

// After — e.g. "apt2aptly-bookworm" or "apt2aptly-v2022-snapshots-20260129T071258Z"
actions.apply(
    &format!(
        "apt2aptly-{}",
        apt_repo.dist.base_dist()
            .replace(|c: char| !c.is_alphanumeric() && c != '-' && c != '_', "-")
    ),
    &upload_opts,
).await?;

base_dist() is used (rather than the full path which includes /snapshots/…) so snapshot runs for the same dist still share a namespace, while different dists are fully isolated.

• Fixes Concurrent uploads with apt2aptly don’t work #71

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[andrewshadura]

I was curious whether or not guarding by component might be useful, so I asked DeepWiki:

---

No: a per-component guard isn't needed, based on how sync_dist actually drives things.

Within a single apt2aptly process, everything is sequential, not concurrent:

• main calls sync_dist once per snapshot in --apt-snapshots (looped, each awaited in turn), then once more for the base dist, all .await?-ed sequentially — never spawned as parallel tasks.

• Inside sync_dist, the for component in scanner.components() loop processes each component one at a time, .await-ing actions.apply("apt2aptly-{dist}", ...) fully (including the upload) before moving to the next component.

So for one dist value, the upload directory apt2aptly-{base_dist} is used by one component's apply() call at a time — there's no overlap between components of the same dist within a single process, because there's no concurrency at that level; the max_parallel option only controls parallelism of file uploads within a single apply() call, not across components or dists.

The concurrency problem the patch fixes is specifically separate OS processes running for different distributions (e.g., two cron/CI invocations for v2022 and v2023 at the same time) colliding on the same shared /api/files/apt2aptly directory. Making the directory name include base_dist() addresses exactly that case.

The only scenario where a per-component split could matter is if two separate apt2aptly process invocations were run concurrently for the same dist value (e.g., someone manually races two runs of the same distribution) — that would still collide on apt2aptly-{dist}, since the directory name doesn't include the component. But that's an unusual/probably unsupported invocation pattern (nothing in main.rs suggests concurrent multi-process runs for the same dist are expected), and it's a different problem class (same-dist double-invocation) than what this patch targets (different-dist concurrent invocations). If that's a real concern in your deployment, you'd want to prevent concurrent same-dist runs entirely (e.g., via a lock) rather than adding a component suffix, since even a component-scoped path wouldn't fully protect other shared state like aptly_published_cache or repo/snapshot creation.

[andrewshadura]

I’m now testing this on a test conversion of Apertis. Seems to work so far for one concurrent instance (so no regressions).
Going to start another instance doing a different release to see if that works now.

[emanueleaina]

Why not coming up with a name that is unlikely to collide instead of picking the dist? UUIDv7 so you can easily spot old stale folders?

Maybe having two instances publishing to same dist works, maybe doesn't, but this surely does not work in that case.

[andrewshadura]

Do we need to run multiple instances uploading the same dist?
I mean, yeah, we could do UUID, but are we sure that’s needed?

[emanueleaina]

Do we need to run multiple instances uploading the same dist? I mean, yeah, we could do UUID, but are we sure that’s needed?

It is just that while we are fixing the issue it seems to be appropriate to fix it generally given it is not much more affort than fixing it partially. Let's fix the our side so at some point we may try to see how the rest of aptly copes with multiple concurrent uploads.