「측정 실패」와 「상류 장애」가 /ops/status 응답에서 구분이 안 된다 — 화면이 문면을 파싱해야 갈린다 (#522 · PR #594)

[junseo2323]

#522 에서 @hd0rable 이 남기신 요청입니다.

@junseo2323 — 화면에서 그 상태(health: DOWN + facts: [] + note 가 「상태를 재지 못했다」)도 그려야 합니다. 상류가 죽은 것과 측정이 실패한 것은 다른 뜻입니다.

그리려고 봤더니 응답으로는 그 둘이 구분이 안 됩니다(PR #594 를 만들면서 실측).

셋이 같은 모양으로 나옵니다

OpsStatusService:120   isolated() 측정 실패     DOWN · latencyMs null · facts []
OpsStatusService:166   database SQLException   DOWN · latencyMs null · facts []
OpsStatusService:177   aiService probe==null    DOWN · latencyMs null · facts []

health 도 latencyMs 도 facts.length 도 같습니다. 남는 것은 note 문면뿐이고, 앞의 것만 "상태를 재지 못했다(" 로 시작합니다.

❗문면 파싱으로 가르지 않았습니다

이 레포가 그 방식을 이미 한 번 명시적으로 버린 자리가 있습니다 — web/src/api/types.ts 의 ErrorCode 주석입니다.

400 두 개를 코드로 가른 이유(결정 1.4): 화면 처리가 다르다 … 문면 파싱으로 가르면 서버 문구가 바뀔 때 조용히 깨진다.

여기도 같은 자리입니다. 게다가 그 문면은 oneLine(e.toString()) 을 품고 있어서 예외 종류에 따라 앞부분이 달라질 수 있고, 화면이 그걸 물면 서버 로그 문구가 화면의 계약이 됩니다.

지금 화면이 하는 것

둘 다 DOWN 카드 + note 를 굵게 냅니다(PR #594). note 안에 「상태를 재지 못했다」가 들어 있으므로 사람은 읽을 수 있습니다 — 못 하는 것은 화면이 그 둘을 다르게 그리는 것입니다. 지금 상태에서 잃는 것은 이만큼입니다.

상류가 죽었다        → 그 구성요소를 본다
측정이 실패했다      → **서버 로그를 본다.** 그 구성요소는 멀쩡할 수도 있다

#522 의 논지가 정확히 "다음 행동이 다르면 갈라야 한다" 였고(AI_SERVICE_UNAVAILABLE 하나로 뭉쳐 있던 셋), 이건 그 논지가 콘솔 안에서 한 겹 더 걸리는 자리입니다.

요청

계약에 신호를 하나 주실 수 있는지 봐 주세요. 모양은 그쪽 판단입니다 — 떠오르는 것 둘만 적습니다.

ⓐ  health 에 값을 하나 더한다     UNKNOWN — 「이 카드는 상태가 아니라 측정이 실패했다」
    ❗web 유니온·문면이 같이 늘어나는 자리입니다(제가 맞춥니다). 다만 「N 벌」 대조와는
      다른 계열이라 ErrorCodeContractTest 는 안 걸립니다.
ⓑ  Component 에 불리언 하나        measured: false
    스키마가 덜 흔들리는 대신, 「health 가 DOWN 인데 measured 가 false」라는 조합을
    읽는 쪽이 해석해야 합니다.

ⓐ 가 낫다고 봅니다 — 이 값이 답하는 질문이 「이 구성요소가 어떤가」인데, 측정 실패는 그 질문에 답을 못 한 것이라 세 값 중 하나가 아니라 네 번째입니다. DOWN 으로 적으면 화면이 「죽었다」를 단정하는데 그건 서버가 모르는 사실입니다. latencyMs 를 못 잰 자리에 0 이 아니라 null 로 준 판단과 같은 모양이라고 봤습니다.

급하지 않습니다 — 지금도 note 로 읽히고, 화면은 신호가 오면 바로 갈라 그립니다. 데모 뒤로 미뤄도 이견 없습니다.

@hd0rable