Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Sandbox routing test fails when TMPDIR lies under ~/.cache (C6 overlap with the per-launch cache projection)

Open
  • Is something wrong?
#301 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
testing

Research direction

Read tests/test_sandbox_routing.py::test_an_all_pi_run_is_sandboxed_in_every_child and the _place_declared Bind branch in src/autoforge/sandbox.py. Reproduce with TMPDIR=$HOME/.cache/tmp on a host that can enforce the sandbox, then inspect how the test chooses its fake Pi install path. Done means make check passes in that setup, the enforced all-Pi run remains covered, and a regression test confirms C6 still refuses a provider path inside a projected location.

Written by the indexing model from the issue text.

Description

Artifact: follow-up defect report (test hermeticity). Found while verifying PRs #296–#300 on 2026-10-23. An AI agent session filed it on the maintainer's instruction, through the maintainer's gh login.

Problem

tests/test_sandbox_routing.py::test_an_all_pi_run_is_sandboxed_in_every_child fails on any host where TMPDIR (and therefore pytest's tmp_path_factory root) lies under $HOME/.cache. The other tests pass there. The test passes on CI, whose runners use /tmp. It fails the same way on an unmodified main (12e10f4), so make check cannot go green on such a host for reasons unrelated to the change under test.

autoforge.errors.SandboxPolicyError: sandbox policy refuses ~/.cache/tmp/pytest-of-<user>/pytest-<n>/pi-install0: C6 overlaps: ~/.cache/tmp/pytest-of-<user>/pytest-<n>/pi-install0 (provider) overlaps the projection ~/.cache/tmp/pytest-of-<user>/pytest-<n>/test_an_all_pi_run_is_sandboxe0/.git/autoforge/sandbox/2/cache
src/autoforge/sandbox.py:1151: SandboxPolicyError

Cause

  • The test places the fake Pi command in tmp_path_factory.mktemp("pi-install") (tests/test_sandbox_routing.py:955).
  • Under required, a launch projects its per-launch cache directory (<git common dir>/autoforge/sandbox/<n>/cache) onto the cache location inside the sandbox.
  • With TMPDIR under ~/.cache, the provider path falls inside that bind's target. _place_declared (src/autoforge/sandbox.py, the isinstance(outer, Bind) branch) then correctly refuses it as C6.
  • The refusal is the policy working as designed. The test assumes its temporary tree is outside every sandbox projection, which the host decides.

A secondary diagnostic point: the message names the bind's source (…/sandbox/2/cache), not its target (the cache location inside the sandbox). The two paths shown do not overlap literally, which makes the refusal hard to read. An operator whose provider command lives under ~/.cache would see the same message.

Reproduce

TMPDIR=$HOME/.cache/tmp uv run pytest -q "tests/test_sandbox_routing.py::test_an_all_pi_run_is_sandboxed_in_every_child"   # fails (needs a host that can enforce the sandbox)
uv run pytest -q --basetemp=/some/dir/outside/home/.cache "tests/test_sandbox_routing.py::test_an_all_pi_run_is_sandboxed_in_every_child"   # passes

Proposed fix

  • Make the test independent of TMPDIR: place the fake Pi install directory outside every path the sandbox projects, or skip with a stated reason when tmp_path_factory's root lies under a projected location. Do not weaken the C6 check.
  • Optionally, name the bind's target as well as its source in the C6 message.

Acceptance

  • make check passes on a capable host with TMPDIR under ~/.cache, and the test still exercises an enforced all-Pi run where the host allows it.
  • The C6 policy is unchanged; a regression test pins the refusal of a provider path inside a projected location.
Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 57m
Merged PRs (30d)
71

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from iceboundrock/AutoForge

All issues in iceboundrock/AutoForge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.