DongHyeonkaandClaude Opus 5
fd221353a3
SSOT 를 저장소에서 확인해 더 보강하고 그것으로 다시 썼다.
§7.2 참조 검사 SQL 을 문자열로 조립하는 실제 코드 — 컴파일러가 표 이름도
컬럼 이름도 보지 않는다는 것이 그 모양에서 드러난다
§11.2 section-heading-rank 가 미디어 쿼리 값을 먼저 걷어내는 이유(테스트 주석)
§16.1 질문 삭제는 참조가 둘뿐이라 같은 문제가 덜하다는 대조
Case 열 편과 Question 셋을 다시 썼다. Question 은 사실·가정·미지수·제약을 갈라
채우고 선택지마다 무엇을 감수하는지 적었다 — 오류 코드를 나누면 계약과 반입한 두
저장소가 함께 움직인다는 것처럼.
SSOT 62,643 → 68,319 자. 검사 넷 전부 통과한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.5 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | |
|---|---|---|---|---|---|---|---|---|---|---|
| CASE | one-cell-failing-took-its-neighbour-down | 한 칸의 실패가 옆 칸을 끌고 내려갔다 | failure-drawn-as-absence | 실패를 없음으로 그린다 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
한 칸의 실패가 옆 칸을 끌고 내려갔다
편집기가 질문과 결정을 하나로 묶어 읽고 있었다. 결정만 터지는데 멀쩡히 오던 질문 목록까지 「불러오지 못했습니다」가 됐다. 더 미묘한 변종도 있었다 — 호출이 동기적으로 던지면 묶는 중에 터져 거절 처리를 지나지도 못한다.
관계
- 화면은 못 읽은 것을 없다고 말하지 않는다 같은 편집기에서 나온 짝이 되는 규칙이다.
- 「이 프로젝트에 열린 질문이 없습니다」 — 실제로는 넷이 있었다 같은 편집기의 다른 부류 실패다.
- 홈의 비교 구역이 세 번 바뀌었다 같은 판단을 주제 탭에 적용한 기록이다.
문제
홈 편집기가 질문과 결정을 한 번에 읽는다. 결정 쪽만 실패해도 화면 전체가 「불러오지 못했습니다」가 됐다.
질문 목록은 정상적으로 오고 있었다.
결론
두 요청을 하나로 묶어 기다리면 한쪽의 실패가 전체를 실패로 만든다. 둘을 따로 읽도록 갈랐다.
더 미묘한 변종이 하나 더 있었다.
Promise.all([gateway.foo()])은 foo 가 거절하는 것만 잡는다. 호출이 동기적으로 던지면 배열을 만드는 중에 터져 rejection handler 를 지나지 못하고, 그러면 홈 focus 한 칸 때문에 대시보드 전체가 빈 화면이 된다.
같은 판단을 주제 탭에도 적용했다.
검증 환경
tech-log-frontend : 6e784ed · fd73bc8 · 3bb724b 확인 방식 : 한쪽 연산만 실패시키고 나머지가 그려지는지 확인
재현 조건
- 편집기가 부르는 두 연산 중 하나만 실패시킨다
- 화면에서 나머지 하나가 그려지는지 본다
- 실패하는 쪽을 동기적으로 던지게 바꾸고 다시 본다
본문
묶어 읽으면 한쪽이 전체를 끌고 내려간다
홈 편집기가 질문 목록과 결정 목록을 하나로 묶어 기다리고 있었다. 결정 쪽 연산에 컨트롤러가 없어 404 가 났고, 화면은 두 목록을 다 못 받은 것으로 그렸다.
질문 목록은 정상적으로 오고 있었다. 묶어 기다리면 하나라도 거절되는 순간 전체가 거절되므로, 성공한 응답이 있어도 쓸 수 없다.
둘을 따로 읽도록 갈랐다. 실패한 목록에만 못 받았다고 적고 나머지는 그대로 그린다.
거절과 던짐이 다른 경로를 탄다
같은 코드에서 더 미묘한 변종이 났다.
Promise.all([gateway.foo()])은 foo 가 거절하는 것만 잡는다. 호출이 동기적으로 던지면 배열을 만드는 중에 터져 rejection handler 를 지나지 못하고, 그러면 홈 focus 한 칸 때문에 대시보드 전체가 빈 화면이 된다.
배열 리터럴 안에서 함수를 부르는 시점은 그 배열이 Promise.all 에 넘어가기 전이다. 그 호출이 동기적으로 던지면 배열이 완성되지 않으므로 Promise.all 이 시작조차 하지 않고, 거기에 붙인 거절 처리기도 붙을 대상이 없다.
거절만 잡는 처리로는 부족하다. 던지는 경로도 함께 잡아야 한 칸의 실패가 화면 전체로 번지지 않는다.
왜 동기적으로 던질 수 있나
게이트웨이 호출이 비동기 함수여도 그 안의 첫 줄이 동기적으로 실행된다. 인자를 검증하거나 연산을 고르는 코드가 거기 있고, 등록되지 않은 연산을 고르면 거기서 바로 던진다.
그래서 「비동기 함수를 불렀으니 거절로 온다」는 전제가 성립하지 않는다.
탭에도 같은 판단을
탭 줄은 목록 호출 하나가 주는 전부이고 상세는 고른 탭만 그때 받는다. 상세 하나를 못 받아도 탭 줄과 나머지 탭은 그대로 그리고, 못 받은 탭에는 못 받았다고 적는다.
이 구조에서는 실패가 번질 수 있는 범위가 처음부터 한 탭으로 좁다. 상세를 미리 다 받아 두는 구조였다면 하나가 실패할 때 어디까지 그릴지를 다시 정해야 했다.
확인하지 못한 것
같은 모양으로 묶어 읽는 곳을 전수로 세지 않았다. 갈라 놓은 것은 홈 편집기와 주제 탭 둘이다.