[Bug] 매칭 재탐색 스케줄러 100건 초과 starvation 수정

[SungKong00]

🐞 버그 설명

매칭 재탐색 스케줄러가 실행될 때마다 REQUESTED 요청을 PageRequest.of(0, 100)으로 조회합니다.

무제한 탐색 정책에서는 조건에 맞는 강사를 찾지 못한 앞쪽 요청이 계속 REQUESTED 상태로 남을 수 있습니다. 다음 스케줄에서도 같은 앞의 100건을 다시 조회하므로, 101번째 이후 요청은 주기 재탐색 기회를 얻지 못할 수 있습니다.

요청 생성 직후에는 각 요청이 즉시 한 번 탐색되므로 “100명까지만 요청 가능”한 문제는 아닙니다. 최초 탐색 후 조건 변경이나 새 강사 노출을 기다리는 재탐색 단계에서 뒤쪽 요청이 굶을 수 있는 공정성 문제입니다.

🔁 재현 시나리오

1. 조건에 맞는 강사가 없는 상태에서 REQUESTED 요청을 101건 이상 생성합니다.
2. 모든 요청이 최초 탐색 후 REQUESTED/SEARCHING으로 남습니다.
3. 101번째 요청에만 맞는 강사가 새로 노출을 시작합니다.
4. 재탐색 스케줄러를 실행합니다.
5. 앞의 100건만 다시 조회되고 101번째 요청은 계속 SEARCHING에 남을 수 있습니다.

✅ 기대 동작

• 대기 요청이 100건을 초과해도 모든 요청이 유한 시간 안에 다시 탐색되어야 합니다.
• 오래된 앞쪽 요청이 계속 REQUESTED여도 뒤쪽 요청이 영구적으로 굶지 않아야 합니다.
• 재탐색 과정에서 같은 요청의 그룹·제안·가격 snapshot이 중복 생성되지 않아야 합니다.

✅ To-do

조회·처리 기준

• 첫 100건 반복 조회가 발생하는 현재 동작을 통합 테스트로 재현한다.
• keyset cursor, 순환 cursor, nextSearchAt/due-order 중 MVP 공정성 기준을 결정한다.
• 단일 scheduler 실행에서 처리할 최대 작업량과 다음 실행으로 넘길 기준을 정한다.
• 일부 요청 처리 실패가 다음 요청의 재탐색을 막지 않게 한다.
• 기존 요청 row 비관적 락과 멱등 skip 동작을 유지한다.

검증

• REQUESTED 요청 101건 이상에서 마지막 요청도 재탐색되는지 검증한다.
• 앞의 100건이 계속 REQUESTED여도 다음 범위가 처리되는지 검증한다.
• 빈 batch와 100건 경계값을 검증한다.
• 재실행 시 그룹·제안·가격 snapshot 중복이 없는지 검증한다.
• scheduler summary log가 전체 조회·성공·실패 수를 정확히 남기는지 확인한다.

✅ 완료 기준

• 100건을 초과한 REQUESTED 요청이 영구적으로 재탐색 대상에서 제외되지 않는다.
• 101건 이상 회귀 테스트가 기존 구현에서는 실패하고 수정 후 통과한다.
• 기존 단건 즉시 탐색, 요청 잠금, 제안 중복 방어 테스트가 모두 통과한다.
• WebSocket 연결 여부와 관계없이 DB/REST 기준 매칭 재탐색이 정상 진행된다.

🔗 관련 이슈

• [Chore] WebSocket 운영 안정화 후속 계획 #109 WebSocket 운영 안정화 통합 계획의 “매칭 스케줄러 공정성과 다중 실행 방어”
• [Chore] 개발·테스트용 seed 데이터 구성 #105 개발·테스트용 seed 데이터 구성

📝 비범위

• WebSocket 재접속
• 다중 인스턴스 distributed lock/lease의 최종 구현
• 매칭 후보 우선순위 정책 변경

[SungKong00]

연관 작업 #132의 seed 계약은 등록된 시나리오를 모두 검증하지만, 100건 초과 재탐색 공정성 수정은 포함하지 않았습니다. starvation 해결은 #123 범위로 그대로 유지합니다.