A terminal failure must survive its own publish failing, and correlation ID must be a validated UUID

[kcrmin]

요약

INT03 통제 재현(run c0df2755-01eb-3660-b57e-be20ab73001a)에서 드러난 두 결함 중 이 저장소 몫을
넘깁니다.

먼저 좋은 소식: 이 이슈의 요청은 INT03 을 막고 있지 않습니다. 1차·2차 장애의 직접 원인은 둘 다
kcrmin 소유(backend 체크섬 handoff, root user-data)이고 그쪽을 고치는 중입니다. 여기 적는 것은 같은
일이 다시 일어났을 때 무한 재시도로 번지지 않게 하는 방어입니다. 급하게 처리하지 않으셔도 됩니다.

---

관찰된 사실 (읽기 전용)

run         c0df2755-01eb-3660-b57e-be20ab73001a
message     d6c7eed3-bc69-40a2-b753-b2c0a7f52253
worker      i-07a6870a8c4c199dc
발생        2026-08-09 10:17:01 KST
배포 root   70cdd868f9daff5644ddd5646bee7ddc0faf5a67
release     https://github.com/Idea2Strategy/Idea2Strategy/actions/runs/31285790795

1차: JobNotSatisfiable: compiled plan sha256:f98de8f7bde5c44eaadf82acad874d9ba7c10eae0d56030687fa706f49a2e850
     is not resolvable
2차: ContractValidationError: backtest_result_event.metadata.correlationId:
     'i-07a6870a8c4c199dc' does not match UUID pattern
결과: HANDLER_ERROR:ContractValidationError 로 attempt 1~5 재시도, run 은 QUEUED 로 남음

이 저장소의 코드는 대체로 옳습니다

wiring.py:1485-1498 은 이미 정확히 옳은 일을 합니다.

try:
    binding = self.bind(envelope, context)
except JobNotSatisfiable as exc:
    self._publish(envelope, self._correlation_id, status="FAILED", ...,
                  failureCode=exc.reason_code, retryable=False)
    return JobOutcome(JobResult.PERMANENT_FAILURE, reason_code=exc.reason_code)

JobNotSatisfiable → terminal FAILED 발행 → PERMANENT_FAILURE(재시도 없음). 구현되어 있습니다.

막힌 이유는 self._correlation_id 가 UUID 가 아니어서 _publish 가 계약 검증에서 던졌고, 그 예외가
__call__ 밖으로 나가 worker.py:548 에서 HANDLER_ERROR 로 바뀐 것입니다. 즉 주입된 설정이 원인이고
로직이 원인이 아닙니다.

그 설정은 root user-data 가 넣습니다 — kcrmin 이 UUID 로 고칩니다.

---

요청 1 — terminal 실패 발행이 실패해도 재시도 루프가 되지 않게

지금은 terminal 결과를 발행하지 못하면 그 예외가 handler 밖으로 나가고, outer worker 가 그것을
HANDLER_ERROR:<타입> 으로 바꿔 RETRY 합니다(worker.py:544-548). 그래서

• 원래 실패 원인(REQUIRED_INPUT_UNAVAILABLE)이 사라지고
• 재시도해도 결코 성공할 수 없는 메시지가 maxReceiveCount 까지 반복되고
• run 은 QUEUED 로 남아 무엇이 문제였는지 아무도 알 수 없습니다

이번에는 발행 실패의 원인이 설정이었지만, 발행은 다른 이유로도 실패할 수 있습니다(계약 변경, 일시적
네트워크, 직렬화). terminal 판정이 이미 내려진 뒤의 발행 실패는 판정을 뒤집어서는 안 됩니다.

제안: bind() 의 except JobNotSatisfiable 블록에서 _publish 를 감싸고, 발행이 실패해도
JobResult.PERMANENT_FAILURE 를 원래 exc.reason_code 로 반환합니다. 발행 실패는 별도로 기록합니다
(로그 + 가능하면 attempt 행의 failure_code).

어느 쪽을 우선할지는 이 저장소의 판단입니다. 다만 원래 실패 코드를 보존하는 것이 핵심입니다 —
HANDLER_ERROR:ContractValidationError 는 진짜 원인을 가립니다.

요청 2 — worker id 와 correlation id 의 의미 분리

production.py:922 이 BACKTEST_WORKER_CORRELATION_ID 를 그대로 correlation id 로 씁니다. 배포 환경은
그 값에 EC2 instance id 를 넣고 있었고(root 에서 고칩니다), 같은 값이 BACKTEST_WORKER_ID 에도 들어갑니다.

두 값은 의미가 다릅니다.

• BACKTEST_WORKER_ID — 누가 실행했는가. instance id 가 적절하고 UUID 일 필요가 없습니다.
• correlation id — 결과 이벤트 계약의 metadata.correlationId. UUID 형식이 계약입니다.

제안: production.py 가 correlation id 를 읽을 때 UUID 로 파싱해 검증하고, 아니면 기동 시점에
ConfigurationError 로 실패합니다. 지금은 잘못된 값이 기동을 통과해 첫 실패 발행 시점까지 숨어
있었습니다. 기동 실패가 훨씬 낫습니다 — BACKTEST_LOG_LEVEL 을 그렇게 하신 것과 같은 방식입니다.

임의 문자열이나 instance id 를 UUID 필드에 넣지 말아 주세요. root 는 인스턴스별로 안정적인 UUID 를
결정론적으로 파생해 공급합니다.

TDD 로 부탁드리는 시험

• JobNotSatisfiable 이 terminal FAILED / REQUIRED_INPUT_UNAVAILABLE 로 발행된다
• 그 발행이 실패해도 결과가 PERMANENT_FAILURE 이고 원래 reason_code 가 보존된다
• 그 경우가 HANDLER_ERROR:* 재시도로 변하지 않는다 (JobResult.RETRY 가 아님)
• correlation id 가 UUID 가 아니면 기동이 실패한다
• 결과 이벤트의 metadata.correlationId 가 UUID 계약을 만족한다

하지 않은 것

기존 run 을 대체·재실행하지 않았고, 신규 공개 release/backtest run 을 만들지 않았고, DLQ 를
receive/delete/redrive 하지 않았고, worker 를 재시작하지 않았고, ASG 를 조작하지 않았고, DB 를 직접
수정하지 않았습니다. 위 사실은 전부 읽기 전용 조회와 소스 확인에서 나왔습니다.

병합 순서

이 이슈의 수정은 INT03 재개를 막지 않습니다. 순서는 이렇게 봅니다.

1. backend 체크섬 handoff 수정 (kcrmin)
2. root user-data UUID correlation id (kcrmin)
3. root 포인터 + Flyway 번들 → 배포 → 검증 (kcrmin)
4. INT03 1회 재개 허가 (kcrmin → hjcud)
5. 이 이슈 — 언제든, 위와 독립 (hjcud)

5번이 먼저 병합되면 3번 배포에 함께 실어 드립니다. 아니면 다음 포인터 갱신에 태우겠습니다.

[kcrmin]

그대로 복사해 붙여넣을 프롬프트

펼치기

backtest-engine 저장소의 이슈 #74 를 해결해줘.

시작 전에:
1. 루트 superproject 에서 AGENTS.md 의 "Launch work loop" 절을 읽고 그대로 따른다.
2. scripts/initialize-local-harness.ps1 -Verify 를 실행한다.
3. .harness/entry.md 와 docs/collaboration-policy.md 를 읽는다.
4. git status --short --branch, git submodule status 로 실제 상태를 확인한다.
5. 다른 세션과 겹치지 않는 전용 worktree 와 fix/74-terminal-failure-survives-publish 계열
   브랜치를 쓴다. backtest-engine 밖의 파일은 바꾸지 않는다 — root user-data 와 backend 는
   kcrmin 이 같은 시각에 고치고 있다.

배경 (읽기 전용으로 이미 확인된 사실):
- run c0df2755-01eb-3660-b57e-be20ab73001a, message d6c7eed3-bc69-40a2-b753-b2c0a7f52253,
  worker i-07a6870a8c4c199dc, 2026-08-09 10:17:01 KST, 배포 root 70cdd868f9daff5644ddd5646bee7ddc0faf5a67
- 1차: JobNotSatisfiable: compiled plan sha256:f98de8f7bde5c44eaadf82acad874d9ba7c10eae0d56030687fa706f49a2e850
  is not resolvable
- 2차: ContractValidationError: metadata.correlationId 'i-07a6870a8c4c199dc' 가 UUID 패턴 위반
- 결과: HANDLER_ERROR:ContractValidationError 로 attempt 1~5 재시도, run 은 QUEUED 로 남음
- wiring.py:1485-1498 의 JobNotSatisfiable -> terminal FAILED 발행 로직은 이미 옳다.
  막힌 원인은 주입된 correlation id 값이고 로직이 아니다.

고칠 것 두 가지:

(1) terminal 판정이 자신의 발행 실패로 뒤집히지 않게 한다.
    wiring.py 의 bind() except JobNotSatisfiable 블록에서 _publish 가 실패해도
    JobResult.PERMANENT_FAILURE 를 원래 exc.reason_code 로 반환해야 한다.
    지금은 그 예외가 __call__ 밖으로 나가 worker.py:548 이
    HANDLER_ERROR:<타입> 으로 바꾸고 RETRY 한다. 그래서 원래 실패 코드가 사라지고
    성공할 수 없는 메시지가 maxReceiveCount 까지 반복된다.
    발행 실패 자체는 따로 기록한다 (로그, 가능하면 attempt 행의 failure_code).

(2) correlation id 를 UUID 로 검증한다.
    production.py:922 가 BACKTEST_WORKER_CORRELATION_ID 를 그대로 쓴다.
    UUID 로 파싱해 검증하고 아니면 기동 시점에 ConfigurationError 로 실패시킨다.
    BACKTEST_LOG_LEVEL 을 잘못된 값에서 기동 실패시킨 것과 같은 방식이다.
    BACKTEST_WORKER_ID(누가 실행했는가, instance id 로 충분)와
    correlation id(결과 이벤트 계약의 UUID)는 의미가 다르므로 분리한다.
    임의 문자열이나 EC2 instance id 를 UUID 필드에 넣지 않는다.
    root 는 인스턴스별로 안정적인 UUID 를 결정론적으로 파생해 공급한다.

TDD 로 진행해줘. 먼저 실패하는 시험을 추가하고 그것이 실제로 실패하는 것을 확인한 뒤 고친다:
- JobNotSatisfiable 이 terminal FAILED / REQUIRED_INPUT_UNAVAILABLE 로 발행된다
- 그 발행이 실패해도 결과가 PERMANENT_FAILURE 이고 원래 reason_code 가 보존된다
- 그 경우가 JobResult.RETRY 로 변하지 않는다
- correlation id 가 UUID 가 아니면 기동이 실패한다
- 결과 이벤트의 metadata.correlationId 가 UUID 계약을 만족한다
- 저장소 전체 회귀 시험을 돌린다

금지:
- 기존 run 대체 또는 재실행
- 신규 공개 release / backtest run 생성
- personal bot run 실행
- 기존 DLQ 메시지 receive / delete / redrive
- worker 수동 재시작, ASG 조작
- DB 직접 insert / update, 임시 grant
- 원인을 확인하지 않은 추가 배포
- backtest-engine 밖 저장소 수정

완료 후:
- develop 대상 PR 을 열고 CI 를 통과시킨다
- 이슈 #74 에 변경 파일, 추가한 시험과 그 실패->통과 결과를 적는다
- 포인터 갱신과 배포는 kcrmin 이 한다. 병합되면 알려주면 다음 배포에 싣는다.
- 이 수정은 INT03 재개를 막지 않는다. 서두르지 않아도 된다.

참고: 이 이슈가 INT03 을 막지 않는 이유

kcrmin 이 root user-data 의 correlation id 를 UUID 로 고치면 _publish 가 성공하고, 이미 구현된
PERMANENT_FAILURE 경로가 그대로 동작해 재시도 루프가 사라집니다. 이 이슈의 (1)은 다른 이유로 발행이
실패할 때를 위한 방어이고, (2)는 같은 실수가 조용히 통과하지 못하게 하는 것입니다.

[hjcud]

Implemented the backtest-engine-owned defenses in draft PR #75: #75

Changes:

• src/backtest_engine/wiring.py: a terminal bind failure preserves PERMANENT_FAILURE and its original reason if failure-event publication raises; the publication exception is logged with run/attempt/reason context.
• src/backtest_engine/production.py: BACKTEST_WORKER_CORRELATION_ID is validated and normalized as a UUID before other worker dependencies are built.
• tests/test_wiring.py, tests/test_production.py: successful terminal publication, publication-failure fallback, no retry result, fail-fast invalid UUID, and canonical UUID coverage.

TDD: the three new regression cases failed before implementation and passed afterward. Full validation passed: ruff, mypy (74 source files), and the Docker-free suite (1240 passed, 3 skipped, 168 deselected).

No AWS run/release, DLQ operation, worker restart, ASG operation, or database mutation was performed. Root pointer and deployment remain with kcrmin.

[hjcud]

CI for draft PR #75 is now fully green: https://github.com/Idea2Strategy/Idea2Strategy-backtest-engine/actions/runs/31290087665

All 9 gates passed, including ruff, mypy, Docker-free tests/coverage, contracts, app smoke, migration contribution, dependency/secret scan, PostgreSQL 16 + LocalStack integration, and LocalStack S3 storage. The branch is ready for review and later root-pointer inclusion by kcrmin.