한 고객 케이스가 모든 엔드포인트에서 500을 뱉기 시작했다 — validation, survey, calculation-method, calculation/run 전부. case 진입 시 usr_survey.case_survey를 읽는데, 그 테이블이 "permission denied for table"였다. 원인은 앞선 migration 145와 똑같았다 — 신규 테이블 추가할 때 GRANT를 빠뜨리는 패턴. migration 147로 두 가지를 고쳤다: 스키마 내 모든 현재 테이블에 GRANT, 그리고 ALTER DEFAULT PRIVILEGES로 아직 존재하지 않는 테이블까지 같은 실수를 못 반복하게. 마감 전에 실제 SELECT 권한으로 검증까지 마쳤다.
한 고객 케이스가 모든 엔드포인트에서 500을 뱉기 시작했다 — validation, survey, calculation-method, calculation/run 전부. case 진입 시 usr_survey.case_survey를 읽는데, 그 테이블이 "permission denied for table"였다. 원인은 앞선 migration 145와 똑같았다 — 신규 테이블 추가할 때 GRANT를 빠뜨리는 패턴. migration 147로 두 가지를 고쳤다: 스키마 내 모든 현재 테이블에 GRANT, 그리고 ALTER DEFAULT PRIVILEGES로 아직 존재하지 않는 테이블까지 같은 실수를 못 반복하게. 마감 전에 실제 SELECT 권한으로 검증까지 마쳤다.
← PREV / 해가 뜨기 전, 토스 결제 콜백이 Cloudflare를 통과하게 만드는 시도 네 번. 새벽 3시2분: successUrl을 직접 fetch하는 대신 프론트 결과 페이지로. 3시38분, fetch() 자체를 포기하며: "fetch → window.location.href (Cloudflare CORS 헤더 제거 우회)" — Cloudflare가 CORS 헤더를 지워버리니, 정중히 요청하길 관뒀다. 4시2분: successUrl을 아예 백엔드 콜백으로 직접 지정, 완전 우회. 6시15분엔 한 번 더 — 프론트 fetch를 통째로 없애고 백엔드 redirect로, "CORS/토큰 완전 우회." 네 커밋, 새벽 세 시간, 상대는 결제 로직이 아니라 네트워크 레이어였다.ARCHIVE / INDEX