Repository navigation
Conversation
Refs #683, #686; preserve genuine webpack process ownership proof Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Codecov Report✅ All modified and coverable lines are covered by tests. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #683, #686 (W70/W82 후속: Windows Next webpack 프로세스 소유권 검증, main
24a595763기반 독립 PR)PR #809 위에 쌓지 않았으며 선행 스택 의존성은 없습니다. theme/key-coercion 후속은 보호된 소유 영역과 겹쳐 별도 보고했고 이 PR에 포함하지 않았습니다. 변경은 기존 테스트 파일 하나와
packages/next-plugin/package.json: Patchchangepack 하나뿐입니다.요약
process.kill(pid, 0)으로 전역 재조회하던 assertion을 제거했습니다. 그 숫자가 이후 무관한 프로세스에 재사용되면 job 정리가 완료되어도 실패하는 잘못된 판단입니다.active: [], 관찰한 복수 PID, 모든 fault descendant의 관찰 여부, 정상/실패 상태, 실제 Next HTML/CSS와 warm-cache 검증 및 fixture의 물리적 삭제를 계속 검사합니다.동작
Windows owner는 실제 프로세스를 suspended 상태로 만들고 실제 handle을 job에 배정한 뒤 실행합니다. 종료 시 정확한 job을 terminate하고 멤버가 0이 될 때까지 기다린 뒤 원래 root HANDLE도 기다립니다. supervisor는 이 성공 뒤에만 같은 job의
tree_exit를 기록하고, 실제 fixture 삭제 성공 뒤에만 cleanup을 기록합니다. 이 구현은 그대로입니다.숫자 PID 목록은 과거 관찰의 증거이지 전역 프로세스 identity의 영구 예약이 아닙니다. 공통 테스트 assertion은 실제 job의 빈 membership과 관찰 증거를 판정하고, 종료 이후 무관한 identity가 같은 숫자를 소유했다는 이유로 이를 뒤집지 않습니다.
재현은 두 층으로 나누었습니다. 결정적 회귀 5개는 같은 assertion seam에서 숫자 재사용/전역 부재/owned survivor/관찰 부족/fault 관찰 누락을 구분합니다. 전역 lookup interception은 동기 호출 안에서만 적용하고
finally에서 복구하며 실제 OS에 signal을 보내지 않습니다. 별도로 실제 설치된 Next, webpack, HTTP/SSR/edge/CSS와 Windows kernel owner를 사용하는 기존 7개 시나리오를 그대로 실행했습니다. 가짜 receipt로 실제 kernel cleanup을 증명했다고 주장하지 않습니다.새로 생기는 오류
새 build error, API 오류 및 생성되는 런타임 표현식은 없습니다. 프로덕션 변환/출력은 바꾸지 않았습니다. 테스트에서 진짜 owned survivor, descendant 관찰 부족 또는 fixture 삭제 실패가 발생하면 종전처럼 실패합니다.
남는 한계
OS scheduler가 실제로 PID를 재사용한 순간을 관찰한 재현은 아닙니다. main의 잘못된 assertion 결정은 좁은 전역 lookup 경계의 결정적 모델로 RED 확인했고, 실제 native 정리 증거는 별도의 진짜 Next 시나리오에서 확인했습니다. 기존 POSIX process-group 경로와 native owner의 보장 범위는 확장하지 않았습니다. 보호된 theme/coercion/추출기 후속은 이 테스트 전용 PR의 완료 주장에 포함하지 않습니다.
검증
24a595763의 기존 global-PID assertion을 그대로 둔 공통 seam: 4 통과 / 1 실패, 유일한 실패는 무관한 identity가 과거 PID를 소유한 경우였습니다. 실제 원인은 기존toThrow()의Received function did not throw / Received value: true입니다. import/timeout 실패를 RED로 세지 않았습니다.active: []와 성공한 물리적 fixture cleanup을 기록했고 post-start-timeout은reason: deadline, exit124를 유지했습니다.verify:dist, 최종 lint 통과. 기본 Rust 스택/jobs2의 workspace 9,428/0/0 ignored.5caa80181454211f7ecb57f84f04c20213b8e8e7에서 commit **9c2e54db2989ecdeb36278cf16ab1f5c20802313**가 생성되었으며 단일 parent는 main24a595763, 작업 트리는 clean입니다. 실제 훅의 루트 6,257/0 및 Vite 868/0, 양쪽 100.00/100.00을 다시 확인했습니다. bypass/amend/force는 없습니다.9c2e54db2989ecdeb36278cf16ab1f5c20802313, 재실행 0회. publish / benchmark / landing-next-e2e / react-18 / vinext-rsc-css-e2e / webpack-extends-theme / release-compat / wasm-size 8개 validation job 모두 통과했습니다. main 전용 release/deploy-pages skip은 예상된 조건부 제외입니다.