What causes "mountpoint was concurrently registered: {}" in astrid-runtime/astrid?

Serialize mount operations for a given path — use an external lock or single mount orchestrator.

mountpoint was concurrently registered: {}

Error message

mountpoint was concurrently registered: {}

What it means

After the native WinFsp mount succeeded, mount() performs a final registry update under its own check-and-insert. If another process inserted the same registry key between the initial check and this update, the mount would be double-booked, so the update bails with this error.

Source

Thrown at crates/astrid-storage-provider-winfsp/src/main.rs:208

    }
    let body = client
        .request(AdminRequestKind::StorageMountIssue {
            view,
            access,
            provider: PROVIDER_NAME.to_owned(),
            mountpoint: mountpoint.clone(),
        })
        .await?;
    let lease = lease_from_response(body)?;
    let control_path = provider_control_path(&lease.mount_id)?;

    if let Err(error) = native_mount(&lease, &mountpoint).await {
        revoke_after_native_failure(client, &lease, auto_created, &mountpoint).await;
        return Err(error);
    }
    let registered = update_registry(|registry| {
        if registry.mounts.contains_key(&registry_key) {
            bail!(
                "mountpoint was concurrently registered: {}",
                mountpoint.display()
            );
        }
        registry.mounts.insert(
            registry_key.clone(),
            MountRecord {
                mount_id: lease.mount_id,
                requested_by: acting_principal,
                mountpoint: mountpoint.clone(),
                resource_path: lease.resource_path.clone(),
                control_path: control_path.clone(),
                access,
                auto_created_mountpoint: auto_created,
            },
        );
        Ok(())
    });

View on GitHub (pinned to affd8760f4)

Solutions

Serialize mount operations for a given path — use an external lock or single mount orchestrator.
Unmount the newly created native mount before retrying, since this error is raised after native_mount already succeeded.
Retry with a different mountpoint path to avoid the collision.
Check which other process owns the registry entry (its requested_by principal) and coordinate with it.

Example fix

// before: parallel mounts of the same path race
join_all(paths.iter().map(|p| mount(p, view, access))).await;
// after: serialize per-path with a lock
let _guard = path_lock("Z:").lock().await;
mount("Z:", view, access).await?;

Defensive patterns

Strategy: retry

Validate before calling

// Prevent the race externally before launching parallel mounts:
let _guard = path_lock(mountpoint).lock().await; // serialize per-path

Try / catch

// Caller
match mount(client, view, access, Some(path)).await {
    Err(e) if e.to_string().starts_with("mountpoint was concurrently registered") => {
        // NOTE: native mount already succeeded; unmount it, then retry on another path
    }
    other => other?,
}

Prevention

Serialize mounts per path with a lock or single orchestrator
Avoid retrying a mount while the previous attempt is still in flight
Run only one provider instance per registry file

When it happens

Trigger: Two provider processes race to mount the same mountpoint: both pass the initial load_registry() check (716), both complete native_mount(), and the loser's update_registry() finds the key already inserted by the winner.

Common situations: Multiple mount requests for the same drive letter issued concurrently by parallel tooling or CI; several provider instances sharing one registry file without external locking; a retried mount launched while the original attempt is still finishing.

Related errors

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/526c12cb70cba5d5. Report an issue: GitHub.