오류 기록을 읽어 달라는 요청에 원래 프로그램의 갱신과 실행이 따라오면 조사 자체가 다른 작업이 될 수 있다. 나는 최근 진단 보고서 구현에서 조사할 기록의 읽기 경로를 따로 둔 선택을 따라갔다. 원래 작업은 그대로 두고 새로 필요한 보고서만 만든다는 말을 코드의 실제 경계로 확인하고 싶었다.
기록을 읽는 함수 안에도 변경이 있을 수 있었다
오류를 조사하려면 먼저 이전 실행의 기록을 읽어야 한다. 그런데 이번 소스의 일반 readRun은 프로그램의 load를 먼저 호출한다. load는 정의의 무결성을 확인하는 역할과 함께 오래된 실행기라면 백업을 만들고 실행기 스크립트와 manifest를 갱신하는 경로도 갖고 있었다. 데이터를 읽는다는 이름만으로 아무것도 바꾸지 않는다고 이해할 수는 없었다.
그 갱신이 원래 실행 준비에 필요할 수 있어도 진단 보고서의 목적과는 다르다. 실패 당시 기록을 보려는 요청에 원래 프로그램의 변환까지 따라오면, 무엇을 조사했고 무엇을 새로 바꿨는지 설명이 어려워진다. 나는 새 보고서가 원본 기록을 읽을 때 이 일반 로더를 거치지 않은 이유를 실제 호출부에서 따라갔다.
보고서를 만드는 실행과 조사할 실행의 이름표를 나눴다
보고서 플러그인도 자신의 정의를 읽고 자신의 실행 기록을 만든다. 이번 설계를 모든 로딩과 파일 쓰기가 없는 기능이라고 설명하면 틀린다. 구별할 대상은 보고서를 만드는 프로그램과 그 보고서가 조사하는 원래 프로그램이다. 새 실행의 programId와 입력으로 받은 원본 programId·runId는 같은 역할의 식별자가 아니다.
원본 쪽은 readOwnedRun으로 현재 프로젝트의 저장 위치에서 읽는다. 영수증 해석 함수는 요청한 실행 ID와 프로그램 ID, 프로필이 실제 기록과 맞는지 비교하고, 요약 함수는 현재 프로젝트에 속한 근거인지 다시 확인한다. 없는 기록을 다른 곳에서 찾아 비슷한 결과로 채우지 않는 것이 이 읽기 경로의 중요한 선택이었다.
보고서 때문에 커널과 페이지 작업을 시작하지 않았다
실행기는 보고서 단계 하나만 있는 정의인지, 별도 탭 구성이 없는지, 정해진 시작값과 한 번 실행 조건을 지키는지 확인한다. 보고서가 섞인 일반 작업 정의를 그대로 실행하지 않으려는 제한이다. 이 분류 뒤에는 Python을 찾아 실행하거나 노트북을 업그레이드하는 일반 경로 대신 내장 보고서 처리가 이어진다.
즉 화면에서 선택한 실행 모드 이름만으로 커널이 시작됐다고 판단할 수는 없다. 다만 보고서 실행기의 상태 기록과 저장 작업까지 없어지는 것은 아니다. 읽어야 할 원본에는 손대지 않으면서 필요한 새 산출물은 만들 수 있도록 책임을 나눈 구조다. 원래 작업을 다시 입력하거나 실행해 진단 자료를 얻는 기능과도 구별했다.
필요 없는 문자열을 지우기보다 보낼 항목을 먼저 정했다
보고서는 원문 전체를 복사한 다음 비밀처럼 보이는 단어를 지우는 방식이 아니다. 허용된 식별자·해시·상태·숫자와 고정 오류 코드로 새 문서를 만든다. 오류 문자열도 허용 목록과 맞는 코드만 남기고 나머지는 UNCLASSIFIED로 표현한다. 답변 안쪽을 재귀적으로 훑어 파일처럼 생긴 모든 객체를 끌어오지 않는다.
파일 정보는 정해진 출력 슬롯에서 크기와 해시 형식이 맞는 기록을 최대 64개 남긴다. 이것은 고유 파일 64개를 실제로 열어 검수했다는 뜻이 아니며, 그 해시를 원본 파일에서 다시 계산하는 단계도 아니다. 원고·답변·파일명·경로·오류 상세를 제외한 설계와 어떤 자료든 공개해도 된다는 판단은 별도로 남겨야 했다.
원래 상태를 고치지 않고 읽는 쪽의 해석을 붙였다
저장된 running은 지금도 실제로 실행 중이라는 보장이 아니다. 요약은 storedStatus를 남기고 진단에서 확인이 필요하다는 상태를 따로 붙인다. 이 표현을 원래 영수증에 덮어쓰는 함수는 아니다. 과거 기록이 남아 있는 상태와 지금 실행이 살아 있는 상태를 같은 것으로 처리하지 않은 것이다.
보고서의 verified 역시 보고서 저장 작업의 결과이지 원래 외부 업무의 성공을 새로 인증한 값이 아니다. 실행 상태와 업무 상태를 나눴던 앞선 글의 원칙이 여기에도 적용된다. 이번 글의 새로운 질문은 그 구분을 지킨 문서를 만들면서 조사 대상의 로딩·갱신 경로까지 피했는가에 있다. 보고서를 더 자세히 만들었다고 재실행 권한이 생기지는 않는다.
새 파일을 저장할 때의 실패도 원래 작업과 구별했다
JSON과 Markdown은 각각 이미 있는 파일을 덮어쓰지 않는 방식으로 저장한다. 읽기 전후와 파일 쓰기 사이에는 취소·현재 실행 확인도 들어간다. 보고서를 만드는 새 작업 자체에도 중간 상태와 실패가 있을 수 있으므로 원래 프로그램의 실패 기록과 구별해서 읽어야 한다.
선택한 함수는 두 파일을 차례로 쓰며 전체를 한 번에 교체하는 트랜잭션이나 쌍 단위 되돌리기를 보여 주지는 않는다. 따라서 첫 파일 뒤에 실패하면 어떤 산출물이 남았는지 확인할 필요가 있다. 이번에는 그 실패를 원제품에서 새로 발생시키지 않았다. 소스의 쓰기 경계를 보고 두 파일이 항상 함께 완성된다고 약속하지 않은 것이다.
기존 구조 보고서 모듈은 다른 경계에서 재사용했다
공개할 때는 기존 합성 구조 보고서 모듈을 다시 사용했다. 이 모듈은 허용한 단계·함수 별칭·오류 코드와 제한된 노드 상태만 받고 여분 원문 필드를 거절한다. 실제 실행 영수증을 읽는 함수나 이번 내장 보고서 플러그인의 복제본은 아니다. 아래 입력은 원본 기록이 아닌 독립적인 교육용 사건이다.
현재 공개 ZIP의 바이트와 해시를 확인하고 추출한 합성 시험 32개를 실행했다. 기존 예제 다섯 개와 추가 구조 입력 하나도 함수로 계산했다. 원래 제품의 916개 회귀나 실제 보고서 세 번 재사용은 기존 제작 보고의 근거이며 이번 실행에서 반복하지 않았다. 실제 브라우저·원고·계정·사적 영수증을 건드리지 않고도 읽기 경로의 선택과 공개 입력의 한계를 함께 설명할 수 있었다.
코드와 구현 살펴보기
기존 모듈에 넣은 독립 합성 입력
from diagnostic_bundle import bundle
event = {'stage': 'verify', 'code': 'OUTCOME_UNKNOWN', 'function': 'verify_input', 'outcome_uncertain': True, 'nodes': []}
summary = bundle([event])