scripts: wait out the gateway's transient refusals in the recovery harness (P1R-C06)

docs/ko/recovery-qualification.md

@@ -59,7 +59,7 @@ env -i HOME="$HOME" TMPDIR="$TMPDIR" PATH="<Rust 1.95.0>/bin:/usr/bin:/bin:/usr/
 
 ## 기능 스위트
 
-시나리오마다 작업 디렉터리, 작업 데이터베이스, Runner를 따로 쓰고, `required`이면 fixture authority도 따로 씁니다. 시나리오가 남긴 실행 중인 것은 그 뒤에 끝냅니다. 시나리오는 확인 항목이 모두 통과해야 통과합니다. 시나리오가 따로 말하지 않으면 gateway의 프로세스 timeout은 10분이고 종료 의도는 `detach`입니다. I/O 칸의 "둘 다"는 pipe로 한 번, PTY로 한 번 실행한다는 뜻이고, 참여 칸은 그 시나리오를 실행하는 참여를 나열합니다.
+시나리오마다 작업 디렉터리, 작업 데이터베이스, Runner를 따로 쓰고, `required`이면 fixture authority도 따로 씁니다. 시나리오가 남긴 실행 중인 것은 그 뒤에 끝냅니다. 시나리오는 확인 항목이 모두 통과해야 통과합니다. 시나리오가 따로 말하지 않으면 gateway의 프로세스 timeout은 10분이고 종료 의도는 `detach`입니다. I/O 칸의 "둘 다"는 pipe로 한 번, PTY로 한 번 실행한다는 뜻이고, 참여 칸은 그 시나리오를 실행하는 참여를 나열합니다. 재시작 직후 gateway는 작업이 시작된 적 있는 workspace마다 그 workspace를 대조할 때까지 새 작업을 `RECOVERY_PENDING`으로 거부합니다. 프로세스를 위해 workspace를 점유한 gateway는 Runner가 그 프로세스를 회수하면 끝났다고 보고하지만, workspace는 프로세스의 출력이 닫혀 Runner의 종료 이벤트가 뒤따를 때에야 풀며, 그때까지 그 workspace의 새 작업을 `WORKSPACE_BUSY`로 거부합니다. 시나리오가 새 작업을 시작해야 할 때는 이 거부 가운데 하나를 받는 동안 최대 30초까지 다시 보내고, 통과 조건이 이 거부 가운데 하나를 기대하는 시나리오는 그 거부를 확인합니다.
 
 <a id="recovery-lifecycle"></a>
 
@@ -147,7 +147,7 @@ env -i HOME="$HOME" TMPDIR="$TMPDIR" PATH="<Rust 1.95.0>/bin:/usr/bin:/bin:/usr/
 
 ### 구간, 주기, 표본
 
-한 번의 반복은 10분 유휴 구간과 그 뒤 30분 이상의 부하 구간이고, 절차는 세 번 반복합니다. 구간마다 새 Runner를 시작하며, 이 Runner는 `codespace` 소비자의 유일한 인스턴스로 등록합니다(결정 D12). 첫 gateway는 구간 내내 실행되는 프로세스를 시작합니다. 각각 25 mCPU, 16 MiB, 2 tasks를 요청하는 관리 대상 workspace의 `cat`(pipe)과 `sleep`(PTY), 그리고 관리하지 않는 workspace에서 0.2초마다 번호 붙은 줄을 쓰는 PTY와, 하네스가 신호를 줄 때마다 출력 ring이 담는 것보다 많은 번호 붙은 줄 40,000개를 한꺼번에 쓰는 pipe입니다. 요청을 받는 gateway가 무엇이든 그것을 통해 `control` 스위트의 일정대로 제어 경로를 표본으로 잽니다([구간과 표본](cs-rg-qualification.md#control-intervals)). status는 1초마다, 새 관리 대상 종료는 20초마다, I/O echo는 5초마다, 관리 대상 거부는 30초마다, 그리고 host, service, footprint(Runner와 gateway의 것)입니다. 두 출력 흐름은 2초마다 읽습니다. 요청을 받는 gateway가 없을 때 돌아온 일정은 표본이 아닌 `restarting`으로 기록하며, 기대하는 표본 수는 gateway가 요청을 받은 시간을 따릅니다.
+한 번의 반복은 10분 유휴 구간과 그 뒤 30분 이상의 부하 구간이고, 절차는 세 번 반복합니다. 구간마다 새 Runner를 시작하며, 이 Runner는 `codespace` 소비자의 유일한 인스턴스로 등록합니다(결정 D12). 첫 gateway는 구간 내내 실행되는 프로세스를 시작합니다. 각각 25 mCPU, 16 MiB, 2 tasks를 요청하는 관리 대상 workspace의 `cat`(pipe)과 `sleep`(PTY), 그리고 관리하지 않는 workspace에서 0.2초마다 번호 붙은 줄을 쓰는 PTY와, 하네스가 신호를 줄 때마다 출력 ring이 담는 것보다 많은 번호 붙은 줄 40,000개를 한꺼번에 쓰는 pipe입니다. 요청을 받는 gateway가 무엇이든 그것을 통해 `control` 스위트의 일정대로 제어 경로를 표본으로 잽니다([구간과 표본](cs-rg-qualification.md#control-intervals)). status는 1초마다, 새 관리 대상 종료는 20초마다, I/O echo는 5초마다, 관리 대상 거부는 30초마다, 그리고 host, service, footprint(Runner와 gateway의 것)입니다. gateway는 모든 workspace를 대조하기 전에 요청을 받기 시작하므로, 요청을 받는 gateway가 종료 대상이나 거부 표본의 실행을 `RECOVERY_PENDING`으로 거부하면 최대 10초까지 다시 보내며, 그때까지도 거부된 종료 대상은 오류입니다. 두 출력 흐름은 2초마다 읽습니다. 요청을 받는 gateway가 없을 때 돌아온 일정은 표본이 아닌 `restarting`으로 기록하며, 기대하는 표본 수는 gateway가 요청을 받은 시간을 따릅니다.
 
 구간은 gateway 주기의 연속입니다. 첫 주기는 20초이고, 그 뒤의 gateway는 모두 프로세스 timeout 20초로 실행을 시작하며, 그 주기의 길이는 그 주기의 timeout 대상이 정합니다. 각 주기에서:
 

docs/recovery-qualification.md

@@ -59,7 +59,7 @@ env -i HOME="$HOME" TMPDIR="$TMPDIR" PATH="<Rust 1.95.0>/bin:/usr/bin:/bin:/usr/
 
 ## Functional suites
 
-Each scenario gets its own work directory, operations database and Runner, and with `required` its own fixture authority; whatever a scenario leaves running is ended afterwards. A scenario passes only when each of its checks passed. Unless a scenario says otherwise, a gateway's process timeout is 10 minutes and its exit intent is `detach`. "Both" in the I/O column means that the scenario runs once with a pipe and once with a PTY, and the participation column lists the participations the scenario runs with.
+Each scenario gets its own work directory, operations database and Runner, and with `required` its own fixture authority; whatever a scenario leaves running is ended afterwards. A scenario passes only when each of its checks passed. Unless a scenario says otherwise, a gateway's process timeout is 10 minutes and its exit intent is `detach`. "Both" in the I/O column means that the scenario runs once with a pipe and once with a PTY, and the participation column lists the participations the scenario runs with. Right after a restart a gateway refuses new work with `RECOVERY_PENDING` in each workspace where work started, until it has reconciled it. A gateway that holds a workspace for a process reports the process exited once the Runner has reaped it, but frees the workspace only when the Runner's exit event follows, once the process's output has closed, and refuses new work there with `WORKSPACE_BUSY` until then. Where a scenario needs new work started, it sends it again while it meets one of these refusals, for up to 30 seconds; where its row expects one of these refusals, it checks it.
 
 <a id="recovery-lifecycle"></a>
 
@@ -147,7 +147,7 @@ The measurement restarts the gateway again and again while governed pipe and PTY
 
 ### Intervals, cycles and samples
 
-A repetition is a 10-minute idle interval followed by a load interval of at least 30 minutes; the protocol has three repetitions. Each interval starts a fresh Runner, which registers as the `codespace` consumer's one instance (decision D12), and its first gateway starts the processes that run the whole interval: a `cat` (pipe) and a `sleep` (PTY) in governed workspaces, which request 25 mCPU, 16 MiB and 2 tasks each, and in ungoverned ones a PTY that writes a numbered line every 0.2 seconds and a pipe that writes 40,000 numbered lines at once, more than the output ring holds, whenever the harness cues it. Through whichever gateway serves, the control path is sampled on the `control` suite's schedules ([intervals and samples](cs-rg-qualification.md#control-intervals)): status every second, a fresh governed termination every 20 seconds, the I/O echo every 5 seconds, a governed refusal every 30 seconds, and the host, service and footprint (the Runner's and the gateway's). Both output streams are read every 2 seconds. A slot that falls while no gateway serves is recorded as `restarting`, not as a sample, and the samples expected follow the time a gateway served.
+A repetition is a 10-minute idle interval followed by a load interval of at least 30 minutes; the protocol has three repetitions. Each interval starts a fresh Runner, which registers as the `codespace` consumer's one instance (decision D12), and its first gateway starts the processes that run the whole interval: a `cat` (pipe) and a `sleep` (PTY) in governed workspaces, which request 25 mCPU, 16 MiB and 2 tasks each, and in ungoverned ones a PTY that writes a numbered line every 0.2 seconds and a pipe that writes 40,000 numbered lines at once, more than the output ring holds, whenever the harness cues it. Through whichever gateway serves, the control path is sampled on the `control` suite's schedules ([intervals and samples](cs-rg-qualification.md#control-intervals)): status every second, a fresh governed termination every 20 seconds, the I/O echo every 5 seconds, a governed refusal every 30 seconds, and the host, service and footprint (the Runner's and the gateway's). Since a gateway serves before it has reconciled every workspace, a termination's target or a refusal's execution that the serving gateway refuses with `RECOVERY_PENDING` is sent again, for up to 10 seconds; a target still refused then is an error. Both output streams are read every 2 seconds. A slot that falls while no gateway serves is recorded as `restarting`, not as a sample, and the samples expected follow the time a gateway served.
 
 The interval is a sequence of gateway cycles. The first lasts 20 seconds; every later gateway starts its executions with a 20-second process timeout, and its cycle is timed by that cycle's timeout target. In each cycle:
 

docs/translations.json

@@ -249,8 +249,8 @@
         "회귀",
         "후보-조합"
       ],
-      "source_sha256": "e49e67542a40b866f58e973546541fd3abf5790416db9726fab9e884c586f43f",
-      "translation_sha256": "01ccea2d97e827ea9d210909ff903b68c5e2bd5d73704a130293e3180ec7632f"
+      "source_sha256": "90775a4bde26e863cf717e0b0af77f9a492ca76cfc9a721e47b52dc97efcd6c9",
+      "translation_sha256": "537841d793983da1d7ac7bd3327355cae57e7b87e64d9deb9be3449a3ee8d1e9"
     },
     {
       "id": "overview",