[Chat] 대화 메시지 목록에 커서 페이지네이션 채택 — 500행 넘는 대화에서 최신 메시지를 못 본다

[Danto7632]

백엔드가 목록 API 에 상한과 커서를 넣었다(Dvely_springboot #341 / PR #353). 본문 JSON 은 예전과 똑같고 파라미터를 안 보내면 기존처럼 동작하지만, 무한 성장을 막느라 상한이 생겼다.

🔴 지금 바로 문제가 되는 것 하나

GET /conversations/{id}/messages 는 파라미터가 없으면 오래된 것부터 500건을 준다(기존 오름차순을 유지했다). 즉 500행이 넘는 대화에서는 최신 메시지가 응답에 없다.

메시지는 사용자 발화 1건당 어시스턴트 메시지가 함께 쌓여 요청 1회에 대략 59행이 생긴다 — 사용자 턴 55100회면 500행에 닿는다. 기본값 500 이 완충이긴 하나 근본 해결은 FE 가 커서를 쓰는 것이다.

계약

커서는 응답 본문이 아니라 헤더로 나간다:

X-Qeploy-Next-Cursor: <id>

헤더가 없으면 마지막 페이지다. 백엔드가 CORS exposedHeaders 에 이 헤더를 넣어 두었으니 브라우저 JS 에서 읽을 수 있다.

엔드포인트	파라미터	기본 / 최대	커서 의미
GET /conversations/{id}/messages	limit, after	500 / 1000	message id, 이후(오름차순)
GET /projects/{id}/changes	limit, after	200 / 500	change id, 이전(최신순)
GET /projects/{id}/approvals	limit, after	200 / 500	approval id, 이전
GET /projects/{id}/domains	limit, after	200 / 500	domain id, 이전
GET /projects/{id}/environment-variables	limit 만	200 / 500	—

커서 값은 숫자 문자열(그 목록의 id)이고, 잘못된 커서는 400 이다.

제안

1. 메시지부터 — 대화를 열 때 최신 쪽을 먼저 보여주려면 limit 을 주고 커서로 위로 거슬러 올라가는 방식이 자연스럽다. 지금은 오름차순이라 "끝까지 받아서 아래로 스크롤" 구조인데, 긴 대화에서 그게 곧 문제다.
2. 나머지 4종은 당장 깨지지 않는다(상한 200에 닿을 일이 드물다). 다만 헤더가 오면 "더 있음" 을 표시하는 정도는 두는 편이 낫다.

참고

백엔드 응답 본문 스키마는 하나도 바뀌지 않았다. 이 이슈는 순수하게 "상한에 걸렸을 때 나머지를 어떻게 가져올 것인가" 다.

관련: Dvely_springboot #341 · PR #353