Linux · Python 3.14 호스트에서 전체 스위트가 33건 실패한다(13259ed 기준 908 passed / 33 failed). 같은 33건이 base dcf2fab 에서도 똑같이 실패하므로 특정 변경의 회귀는 아니고, 테스트가 호스트 환경에 의존하는 문제다.
원인별 분류
테스트
건수
원인
확인 수준
tests/test_workspace_scope.py:27
1
subprocess.run(..., shell=True) 안에서 source 사용. /bin/sh 가 dash 라 source: not found(rc 127)
셸 명령이 source 를 쓰면 executable="/bin/bash" 또는 bash -c 로 실행한다.
테스트는 기본으로 MAM_ENV_FILE 을 빈 파일로 고정해 실제 .mam.env 를 읽지 않게 한다(conftest autouse, #20 과 같은 격리 계열). 실제 브로커를 쓰는 테스트는 명시적으로 옵트인한다.
argparse help 캡처 비교는 버전에 덜 민감한 형태(옵션 목록 비교 등)로 바꾸거나 버전별 캡처를 둔다.
서브모듈이 없으면 deploy 테스트를 skip(사유 명시)한다.
purge 12건의 원인을 조사한다.
환경 정보
Linux 7.0.0-31-generic, Python 3.14.7 (linuxbrew), /bin/sh = dash
main 13259ed / base dcf2fab, 2026-09-14
## 증상
Linux · Python 3.14 호스트에서 전체 스위트가 **33건 실패**한다(`13259ed` 기준 908 passed / 33 failed). 같은 33건이 base `dcf2fab` 에서도 똑같이 실패하므로 특정 변경의 회귀는 아니고, 테스트가 호스트 환경에 의존하는 문제다.
## 원인별 분류
| 테스트 | 건수 | 원인 | 확인 수준 |
|---|---|---|---|
| `tests/test_workspace_scope.py:27` | 1 | `subprocess.run(..., shell=True)` 안에서 `source` 사용. `/bin/sh` 가 dash 라 `source: not found`(rc 127) | 로그로 확인 |
| `tests/test_issue6_fail_closed.py:156` `test_t1_4_broker_unavailable_fail_closed` | 1 | 워크스페이스의 실제 `.mam.env`(도달 가능한 브로커 설정)를 읽어 "브로커 불가" 전제가 깨진다. `MAM_ENV_FILE` 을 없는 파일로 고정하면 통과 | 리뷰(de514a32)와 A/B 로 확인 |
| `tests/test_issue5_phase1_delegation.py:500` `test_shim_help_output_matches_pre_move_capture` | 1 | Python 3.14 argparse help 형식 변화로 캡처와 불일치 | 리뷰(de514a32)의 분류, 직접 확인은 안 함 |
| `tests/test_deploy_freshness.py` d11–d19, d22–d30 | 18 | `nats-docker` 서브모듈 미초기화 | 리뷰의 분류 |
| `tests/test_issue10_13_purge.py` | 12 | **원인 미조사** | — |
## 제안
1. 셸 명령이 `source` 를 쓰면 `executable="/bin/bash"` 또는 `bash -c` 로 실행한다.
2. 테스트는 기본으로 `MAM_ENV_FILE` 을 빈 파일로 고정해 실제 `.mam.env` 를 읽지 않게 한다(conftest autouse, #20 과 같은 격리 계열). 실제 브로커를 쓰는 테스트는 명시적으로 옵트인한다.
3. argparse help 캡처 비교는 버전에 덜 민감한 형태(옵션 목록 비교 등)로 바꾸거나 버전별 캡처를 둔다.
4. 서브모듈이 없으면 deploy 테스트를 `skip`(사유 명시)한다.
5. purge 12건의 원인을 조사한다.
## 환경 정보
- Linux 7.0.0-31-generic, Python 3.14.7 (linuxbrew), `/bin/sh` = dash
- main `13259ed` / base `dcf2fab`, 2026-09-14
tests/test_workspace_scope.py: shell=True(dash) 대신 ["bash","-c", …] — dash 에는 source 가 없다.
tests/conftest.py autouse: MAM_ENV_FILE 을 존재하지 않는 경로로 고정 — 실 .mam.env 를 읽어 브로커 설정이 달라지던 테스트 격리.
tests/test_issue5_phase1_delegation.py: argparse 도움말 캡처 비교를 _normalize_help 로 정규화(py3.10+ 의 options:).
tests/test_deploy_freshness.py d11–d19·d22–d30: private-server 문서 / docker 자산이 없으면 skip(자산이 있는 호스트에서는 그대로 실행).
lib_py/agents/base.py, lib_py/delegation/heartbeat.py: 프로세스 스캔을 POSIX ps -eo pid=,ppid=,args= 로 통일 — purge 12건의 원인 가설(BSD 전용 -axo … command= 를 procps 가 다르게 해석). macOS 에서는 두 형태의 출력이 동일함을 확인했다.
tests/test_issue14_delivery_ack.py: 벽시계 close 여유 timeout_s + 15(부하 시 flake).
확인 부탁: Linux/py3.14 호스트에서 main(6fc9194)으로 전체 스위트를 다시 돌려 purge 12건이 실제로 통과하는지 알려 달라. 통과하면 이 이슈를 닫고, 남는 실패가 있으면 여기 실패 전문을 붙여 달라.
## v4.7.0 (PR #29, `7a94ba2`) 에 반영 — Linux 호스트 확인 요청
33건을 삭제하지 않고 모두 환경 의존성 제거로 처리했다:
- `tests/test_workspace_scope.py`: `shell=True`(dash) 대신 `["bash","-c", …]` — dash 에는 `source` 가 없다.
- `tests/conftest.py` autouse: `MAM_ENV_FILE` 을 존재하지 않는 경로로 고정 — 실 `.mam.env` 를 읽어 브로커 설정이 달라지던 테스트 격리.
- `tests/test_issue5_phase1_delegation.py`: argparse 도움말 캡처 비교를 `_normalize_help` 로 정규화(py3.10+ 의 `options:`).
- `tests/test_deploy_freshness.py` d11–d19·d22–d30: private-server 문서 / docker 자산이 없으면 skip(자산이 있는 호스트에서는 그대로 실행).
- `lib_py/agents/base.py`, `lib_py/delegation/heartbeat.py`: 프로세스 스캔을 POSIX `ps -eo pid=,ppid=,args=` 로 통일 — purge 12건의 원인 **가설**(BSD 전용 `-axo … command=` 를 procps 가 다르게 해석). macOS 에서는 두 형태의 출력이 동일함을 확인했다.
- `tests/test_issue14_delivery_ack.py`: 벽시계 close 여유 `timeout_s + 15`(부하 시 flake).
**확인 부탁**: Linux/py3.14 호스트에서 main(`6fc9194`)으로 전체 스위트를 다시 돌려 purge 12건이 실제로 통과하는지 알려 달라. 통과하면 이 이슈를 닫고, 남는 실패가 있으면 여기 실패 전문을 붙여 달라.
PR #32 본문에 따르면 작성 호스트(Linux)의 기준 실패는 v4.7.0(6fc9194)에서도 12건, 모두 tests/test_issue10_13_purge.py 다. 즉 7a94ba2 의 ps -eo pid=,ppid=,args= 통일은 이 12건의 원인이 아니었다(나머지 21건은 해소된 것으로 보인다). 이 이슈는 열어 둔다.
의 출력(첫 실패의 전체 트레이스백). macOS 에서는 재현되지 않으므로 실패 메시지가 있어야 원인을 좁힐 수 있다.
## purge 12건은 v4.7.0 에서도 Linux 에서 실패 — `ps` 인자 가설 기각
PR #32 본문에 따르면 작성 호스트(Linux)의 기준 실패는 v4.7.0(`6fc9194`)에서도 **12건, 모두 `tests/test_issue10_13_purge.py`** 다. 즉 `7a94ba2` 의 `ps -eo pid=,ppid=,args=` 통일은 이 12건의 원인이 아니었다(나머지 21건은 해소된 것으로 보인다). 이 이슈는 열어 둔다.
다음 확인에 필요한 것: Linux 호스트에서
```
.venv/bin/python -m pytest -p no:cacheprovider -q tests/test_issue10_13_purge.py -x --tb=long 2>&1 | tail -60
```
의 출력(첫 실패의 전체 트레이스백). macOS 에서는 재현되지 않으므로 실패 메시지가 있어야 원인을 좁힐 수 있다.
21건(dash 의 source, 실제 .mam.env 로드, argparse 도움말, 서브모듈)은 앞서 테스트 격리 수정으로 해소됐다.
남은 tests/test_issue10_13_purge.py agy 12건은 v4.9.8(#64, PR #65) 이후 Linux 에서 통과한다(#64 의 Linux 확인 댓글).
원인: agy verify_artifact 가 대화 DB 를 쓰기 가능으로 열었다. 닫을 때 Linux SQLite 가 픽스처의 -wal/-shm 을 지워 테스트의 전제가 깨졌다.
v4.9.8 에서 이 열기가 읽기 전용(_ro_connect)으로 바뀌어 함께 풀렸다. 앞서 의심한 ps 인자 차이는 원인이 아니었다.
Linux(Python 3.14) 전체 스위트: 2080 passed, 20 skipped, 0 failed.
## 닫음: 33건 모두 해소
- 21건(dash 의 `source`, 실제 `.mam.env` 로드, argparse 도움말, 서브모듈)은 앞서 테스트 격리 수정으로 해소됐다.
- 남은 `tests/test_issue10_13_purge.py` agy 12건은 v4.9.8(#64, PR #65) 이후 Linux 에서 통과한다(#64 의 Linux 확인 댓글).
- 원인: agy `verify_artifact` 가 대화 DB 를 쓰기 가능으로 열었다. 닫을 때 Linux SQLite 가 픽스처의 `-wal`/`-shm` 을 지워 테스트의 전제가 깨졌다.
- v4.9.8 에서 이 열기가 읽기 전용(`_ro_connect`)으로 바뀌어 함께 풀렸다. 앞서 의심한 `ps` 인자 차이는 원인이 아니었다.
- Linux(Python 3.14) 전체 스위트: 2080 passed, 20 skipped, 0 failed.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
증상
Linux · Python 3.14 호스트에서 전체 스위트가 33건 실패한다(
13259ed기준 908 passed / 33 failed). 같은 33건이 basedcf2fab에서도 똑같이 실패하므로 특정 변경의 회귀는 아니고, 테스트가 호스트 환경에 의존하는 문제다.원인별 분류
tests/test_workspace_scope.py:27subprocess.run(..., shell=True)안에서source사용./bin/sh가 dash 라source: not found(rc 127)tests/test_issue6_fail_closed.py:156test_t1_4_broker_unavailable_fail_closed.mam.env(도달 가능한 브로커 설정)를 읽어 "브로커 불가" 전제가 깨진다.MAM_ENV_FILE을 없는 파일로 고정하면 통과tests/test_issue5_phase1_delegation.py:500test_shim_help_output_matches_pre_move_capturetests/test_deploy_freshness.pyd11–d19, d22–d30nats-docker서브모듈 미초기화tests/test_issue10_13_purge.py제안
source를 쓰면executable="/bin/bash"또는bash -c로 실행한다.MAM_ENV_FILE을 빈 파일로 고정해 실제.mam.env를 읽지 않게 한다(conftest autouse, #20 과 같은 격리 계열). 실제 브로커를 쓰는 테스트는 명시적으로 옵트인한다.skip(사유 명시)한다.환경 정보
/bin/sh= dash13259ed/ basedcf2fab, 2026-09-14v4.7.0 (PR #29,
7a94ba2) 에 반영 — Linux 호스트 확인 요청33건을 삭제하지 않고 모두 환경 의존성 제거로 처리했다:
tests/test_workspace_scope.py:shell=True(dash) 대신["bash","-c", …]— dash 에는source가 없다.tests/conftest.pyautouse:MAM_ENV_FILE을 존재하지 않는 경로로 고정 — 실.mam.env를 읽어 브로커 설정이 달라지던 테스트 격리.tests/test_issue5_phase1_delegation.py: argparse 도움말 캡처 비교를_normalize_help로 정규화(py3.10+ 의options:).tests/test_deploy_freshness.pyd11–d19·d22–d30: private-server 문서 / docker 자산이 없으면 skip(자산이 있는 호스트에서는 그대로 실행).lib_py/agents/base.py,lib_py/delegation/heartbeat.py: 프로세스 스캔을 POSIXps -eo pid=,ppid=,args=로 통일 — purge 12건의 원인 가설(BSD 전용-axo … command=를 procps 가 다르게 해석). macOS 에서는 두 형태의 출력이 동일함을 확인했다.tests/test_issue14_delivery_ack.py: 벽시계 close 여유timeout_s + 15(부하 시 flake).확인 부탁: Linux/py3.14 호스트에서 main(
6fc9194)으로 전체 스위트를 다시 돌려 purge 12건이 실제로 통과하는지 알려 달라. 통과하면 이 이슈를 닫고, 남는 실패가 있으면 여기 실패 전문을 붙여 달라.purge 12건은 v4.7.0 에서도 Linux 에서 실패 —
ps인자 가설 기각PR #32 본문에 따르면 작성 호스트(Linux)의 기준 실패는 v4.7.0(
6fc9194)에서도 12건, 모두tests/test_issue10_13_purge.py다. 즉7a94ba2의ps -eo pid=,ppid=,args=통일은 이 12건의 원인이 아니었다(나머지 21건은 해소된 것으로 보인다). 이 이슈는 열어 둔다.다음 확인에 필요한 것: Linux 호스트에서
의 출력(첫 실패의 전체 트레이스백). macOS 에서는 재현되지 않으므로 실패 메시지가 있어야 원인을 좁힐 수 있다.
닫음: 33건 모두 해소
source, 실제.mam.env로드, argparse 도움말, 서브모듈)은 앞서 테스트 격리 수정으로 해소됐다.tests/test_issue10_13_purge.pyagy 12건은 v4.9.8(#64, PR #65) 이후 Linux 에서 통과한다(#64 의 Linux 확인 댓글).verify_artifact가 대화 DB 를 쓰기 가능으로 열었다. 닫을 때 Linux SQLite 가 픽스처의-wal/-shm을 지워 테스트의 전제가 깨졌다._ro_connect)으로 바뀌어 함께 풀렸다. 앞서 의심한ps인자 차이는 원인이 아니었다.