한 채널에 대해 시험용 channel_jobs 세 건을 INSERT 로 직접 넣었는데 계속 실행이 안 됐다. started_at 이 몇 분을 기다려도 NULL 이었다.
Table of contents
Open Table of contents
원인 — 두 갈래의 실행 등록
작업을 집어 가는 Kernel.php 를 읽으니 같은 jobs:run 커맨드가 두 형태로 등록돼 있었다. 하나는 --event= 값을 인자로 붙여 여러 번 등록되고 다른 하나는 --channel= 로 채널별로 반복 등록된다.
앞의 것은 --event 가 붙으면 커맨드가 event 컬럼으로 조건을 걸어서 값이 NULL 인 작업을 안 집는다. 뒤의 것은 event 필터 없이 channel_id 만 보므로 비어 있어도 집는다. 같은 커맨드가 인자에 따라 다른 모집단을 보고 있었다.
5분 지연 필터
커맨드를 더 읽으니 created_at < NOW() - INTERVAL 5 MINUTE 로 생성된 지 5분이 지난 것만 집는 조건도 있었다. 방금 넣은 작업은 최소 한 사이클 뒤부터 대상이 된다.
이유는 트랜잭션이 커밋되기 전에 스케줄러가 집어 가는 것을 막으려는 것으로 보인다. 삽입 직후의 미처리를 실패로 판정하면 그 조건을 모른 채 다른 곳을 뒤지게 된다.
판단 기준 — 코드로 확정된 두 제약
여기까지로 두 가지가 정해졌다. 수동으로 넣을 때 event 값이 어느 경로에 걸리는지를 먼저 봐야 하고 --channel 실행을 노리면 비워 둬도 되지만 --event 실행만 도는 채널이면 비워 두면 영영 안 집힌다.
다른 하나는 삽입 직후의 미처리가 정상이라는 것이다. 두 제약 모두 코드에서 확정됐다.
주의 — 설명하지 못한 관측
그런데 5분 주기를 기다린 뒤에도 여전히 미실행이었다. 내가 찾은 두 제약은 사실이지만 이번 관측을 설명하지는 못한다는 뜻이다.
기록에는 두 가지 방법이 있었는데 찾은 제약 둘을 원인으로 적고 닫는 것과 픽업 조건은 코드로 확정했으나 이 제약이 이번 미픽업을 설명하는지는 확정되지 않았다고 나눠 적는 것이다. 뒤쪽을 골랐다. 이유는 5분을 기다린 뒤에도 안 돌았다는 관측이 앞쪽과 모순돼서다. 대신 결론 없이 끝나는 기록이라 읽는 쪽이 개운하지 않은 것을 감수했다. 찾은 것과 설명된 것을 구분해 적지 않으면 다음 사람이 그 선에서 조사를 멈춘다. 채널 지정 실행이 그 채널에 대해 안 돌고 있을 수도 있고 다른 조건이 더 있을 수도 있다.
절반의 확정
이런 상황에서 모르겠다로 끝내지 않는 것이 중요했다. 두 실행 경로의 필터 차이와 5분 지연 필터는 다음에도 쓸 수 있는 확정된 지식이다.
이번 건이 왜 안 도는지는 미확정으로 남았다. 앞의 것만으로도 수동 삽입할 때 무엇을 봐야 하는지는 정해지므로 확정된 것은 확정으로 아닌 것은 아닌 것으로 적었다. 섞으면 둘 다 못 쓰게 된다.
정리
- 같은 커맨드가 여러 인자로 여러 번 등록돼 있을 수 있다
--event인자가 붙으면event가NULL인 작업은 안 집힌다- 생성 후 지연 필터가 있으면 방금 넣은 것은 바로 안 돈다
- 수동 삽입 시 그 값이 어느 경로에 걸리는지 먼저 본다
- 삽입 직후의 미처리를 실패로 판정하지 않는다
- 찾은 것과 설명된 것을 구분해 적는다
- 섞으면 다음 사람이 거기서 멈춘다
- 절반이라도 확정된 것은 확정으로 적는다