Skip to content

Report bounded inventory timeout progress separately from pending changes #732

Open

Description

@Meta-Develop

Summary

maco worktree create can report a capability-bound cleanliness failure when the underlying failure is a bounded repository inventory timeout, but the diagnostic omits the directory being inspected and the completed inventory count. This makes a clean-repository timeout difficult to distinguish from pending changes or unusually large ignored/nested trees.

Expected behavior

Preserve the fail-closed inventory gate and report the bounded failure class, current relative directory, elapsed time, and entries inspected. The pending-changes remediation should be used only when pending changes were actually observed.

Actual behavior

A clean Linux-native repository under a delegated user-systemd scope failed before any worker dispatch with:

managed worktree creation requires a capability-bound repository cleanliness input; commit, stash, or remove pending changes in the primary repository

The actual cause was repository inventory exceeded its time limit before directory stream open. A subsequent ordinary Git status reported no pending changes. A later contained attempt created the first worktree, so the observed failure is timing-sensitive; no deterministic root-cause or deadline change is claimed.

Reproduction context

  • MACO source: 43d5bec351032848af141e1a4fde06c88a3a32ce.
  • Linux/WSL, cgroup v2, delegated user-systemd scope.
  • Launch through the project MACO wrapper: worktree create <name> --repo <clean-repository> --base HEAD --json.
  • Repository includes an ignored nested package checkout and ordinary tracked project context.

Evidence

The error stack reaches validate_bounded_git_text_inputs_bound in src/worktree/part4.rs, then BoundedTreeWalker, InventoryBudget::ensure_before_deadline, and inventory_directory_entries in src/safe_state/part2.rs. The message names the phase but does not retain the relative directory or progress at rejection.

Impact

Operators receive instructions to commit, stash, or remove changes that were not established as the cause. A structured timeout diagnostic would support a bounded investigation while retaining every containment and cleanliness requirement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions