Document coldmail IR loading message bug
This commit is contained in:
parent
4673dbf502
commit
912c1535e5
@ -76,6 +76,7 @@
|
||||
|
||||
- [디버그 인덱스](./debug/README.md) – 구현 직전 단계에서 문제 지점과 상태 차이를 고정하는 보조 문서 계층
|
||||
- [콜드메일 IR 분석이 첫 번째 PDF를 잘못 선택하는 상태](./debug/260313_coldmail_ir_분석대상_오선택_디버그.md)
|
||||
- [콜드메일 IR 분석 로딩 메시지가 완료 후 갱신되지 않는 상태](./debug/260313_coldmail_ir_로딩메시지_미갱신_디버그.md)
|
||||
|
||||
## Worklog Journey
|
||||
|
||||
|
||||
104
journey/debug/260313_coldmail_ir_로딩메시지_미갱신_디버그.md
Normal file
104
journey/debug/260313_coldmail_ir_로딩메시지_미갱신_디버그.md
Normal file
@ -0,0 +1,104 @@
|
||||
---
|
||||
tags: [debug, coldmail, slack, ir, loading, rb8001]
|
||||
---
|
||||
|
||||
# 콜드메일 IR 분석 로딩 메시지가 완료 후 갱신되지 않는 상태
|
||||
|
||||
**작성일**: 2026-03-13
|
||||
**상태**: open
|
||||
**상위 원칙**: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md), [문서 작성 원칙](../../book/300_architecture/312_writing-principles.md)
|
||||
|
||||
## 관련 문서
|
||||
- [Debug 인덱스](./README.md)
|
||||
- [콜드메일 IR 분석대상 선택 정합화 계획](../plans/260313_coldmail_ir_분석대상_선택_정합화_계획.md)
|
||||
- [Pydantic AI 도입 기반 LLM 출력 안정화 종료 리서치](../research/260313_pydantic_ai_도입_기반_llm_출력_안정화_종료_리서치.md)
|
||||
|
||||
## 1. 이 문서의 역할
|
||||
- 이 문서는 콜드메일 IR 분석 Slack UX에서 `로빙 중…` 메시지가 왜 남는지와, 현재 연결이 어디서 어긋나는지를 고정합니다.
|
||||
- 구현 방법, 수정 순서, 배포 검증은 다음 `plans` 또는 `worklog`에서 다룹니다.
|
||||
- 이 문서는 "삭제가 안 돼서 남는다"가 아니라 "이미 있는 update 경로를 IR 분석 흐름이 쓰지 않는다"는 상태를 선명하게 남기기 위한 디버그입니다.
|
||||
|
||||
## 2. 문제 한 줄 정의
|
||||
- 현재 콜드메일 IR 분석은 같은 쓰레드에 `:robot_face: 로빙 중…` 로딩 메시지를 먼저 보내지만, 분석 완료 후 그 메시지를 `완료/오류 상태`로 갱신하지 않아 진행중 표시가 그대로 남습니다.
|
||||
|
||||
## 3. 현재 상태
|
||||
|
||||
### 3.1 오늘 실제 확인된 상태
|
||||
- Slack 쓰레드 `C09LA0D6M1C / thread_ts=1773388822.012659`에서 다음 순서가 실제로 관찰됐습니다.
|
||||
- `:robot_face: 로빙 중…`
|
||||
- `IR Deck 분석 완료`
|
||||
- `종합 점수: 100점 (B등급)`
|
||||
- 이후 같은 쓰레드에 올바른 문서로 재분석한 결과 `75점 (B등급)`을 다시 보냈지만, 기존 `로빙 중…` 메시지는 여전히 남아 있습니다.
|
||||
- 즉 현재 UX는 "진행중 표시가 완료 상태로 치환되는 구조"가 아니라 "진행중 메시지 + 완료 메시지 병존 구조"입니다.
|
||||
|
||||
### 3.2 현재 코드가 만드는 상태
|
||||
- `rb8001/app/services/slack/coldmail_service.py`의 `handle_coldmail_analyze_ir()`는 로딩 메시지를 `send`로 전송하고 `loading_ts`를 받습니다.
|
||||
- 하지만 분석 완료 후에는 그 `loading_ts`를 사용해 `update`를 호출하지 않고, 별도의 새 완료 메시지를 다시 `send`합니다.
|
||||
- 코드 주석도 여전히 "로딩 메시지 삭제는 skill-slack에 delete 엔드포인트가 없으므로 생략"이라고 적혀 있습니다.
|
||||
- 반면 같은 파일의 `handle_coldmail_confirm()` 흐름은 로딩 메시지를 보낸 뒤 `loading_ts`를 사용해 `/api/v1/update`로 상태를 바꾸는 경로를 이미 사용합니다.
|
||||
|
||||
### 3.3 skill-slack의 실제 기능 상태
|
||||
- `skill-slack`에는 메시지 삭제 엔드포인트는 없지만, 메시지 갱신용 `POST /api/v1/update`는 이미 존재합니다.
|
||||
- 이 엔드포인트는 Slack `chat_update`를 호출하므로, 로딩 메시지를 완료/오류 상태로 치환하는 데 필요한 기능은 이미 준비돼 있습니다.
|
||||
- 따라서 현재 문제는 `skill-slack 기능 부족`이 아니라 `rb8001의 IR 분석 흐름이 기존 update 경로를 사용하지 않는 상태`입니다.
|
||||
|
||||
## 4. 기대 상태
|
||||
|
||||
### 4.1 UX 기준 기대 상태
|
||||
- 사용자가 IR 분석 버튼을 누르면 같은 쓰레드에 잠시 `로빙 중…`이 보일 수 있습니다.
|
||||
- 분석이 끝나면 그 로딩 메시지는 `분석 완료`, `분석 실패`, 또는 이에 준하는 최종 상태로 갱신되어야 합니다.
|
||||
- 사용자는 쓰레드 안에서 "아직 진행중인지", "이미 끝났는지"를 메시지 하나의 상태 변화만으로 이해할 수 있어야 합니다.
|
||||
|
||||
### 4.2 시스템 기준 기대 상태
|
||||
- `handle_coldmail_analyze_ir()`는 `loading_ts`를 받은 경우, 완료/실패 시점에 같은 메시지를 `update`해야 합니다.
|
||||
- `로빙 중…`와 최종 결과가 서로 다른 별도 메시지로 중복 노출되지 않아야 합니다.
|
||||
- confirm 흐름과 IR 분석 흐름이 같은 로딩 메시지 UX 패턴을 따라야 합니다.
|
||||
|
||||
## 5. 문제 지점
|
||||
|
||||
### 5.1 IR 분석 흐름의 미연결 지점
|
||||
- `rb8001/app/services/slack/coldmail_service.py`
|
||||
- 로딩 메시지 생성: `handle_coldmail_analyze_ir()` 내부 `SKILL_SLACK_URL/api/v1/send`
|
||||
- 완료 메시지 전송: 같은 함수 내부 `SKILL_SLACK_URL/api/v1/send`
|
||||
- 중간에 `loading_ts`를 이용한 `update` 호출이 없습니다.
|
||||
|
||||
### 5.2 동일 파일 내 비교 기준
|
||||
- `rb8001/app/services/slack/coldmail_service.py`
|
||||
- `handle_coldmail_confirm()`는 `loading_ts`를 저장하고, fallback/오류 시 `SKILL_SLACK_URL/api/v1/update`를 사용합니다.
|
||||
- 즉 같은 모듈 안에서도 confirm 흐름은 "로딩 메시지 갱신"을 알고 있고, IR 흐름만 그 패턴이 빠져 있습니다.
|
||||
|
||||
### 5.3 하위 스킬의 실제 지원 상태
|
||||
- `skill-slack/app/api/endpoints/messages.py`
|
||||
- `POST /send`: `chat_postMessage`
|
||||
- `POST /update`: `chat_update`
|
||||
- "delete가 없어서 못 한다"는 것은 부분 사실일 뿐이고, 실제 기대 UX를 만들기에는 `update`만으로 충분합니다.
|
||||
|
||||
## 6. 왜 이것이 버그인가
|
||||
|
||||
### 6.1 사용자 관점
|
||||
- 완료 메시지가 왔는데도 `로빙 중…`이 그대로 남아 있으면, 분석이 끝난 것인지 추가 처리가 남은 것인지 즉시 구분하기 어렵습니다.
|
||||
- 같은 쓰레드 안에서 진행중 상태와 완료 상태가 동시에 보이면 UX 신뢰도가 떨어집니다.
|
||||
|
||||
### 6.2 구현 관점
|
||||
- 코드가 `loading_ts`를 이미 받아놓고도 최종 상태 갱신에 사용하지 않는 것은 흐름 연결 누락입니다.
|
||||
- 더구나 동일 모듈에 이미 동작하는 `update` 패턴이 존재하므로, 현재 상태는 의도된 단순 설계라기보다 경로 불일치에 가깝습니다.
|
||||
|
||||
### 6.3 문서/주석 관점
|
||||
- IR 분석 경로의 주석은 `delete 엔드포인트 부재`를 이유로 들지만, 실제 필요 기능은 `delete`가 아니라 `update`입니다.
|
||||
- 즉 코드 주석의 전제가 현재 skill-slack capability와 맞지 않습니다.
|
||||
|
||||
## 7. 확인된 사실
|
||||
- `skill-slack/app/api/endpoints/messages.py`에는 `POST /update`가 구현돼 있습니다.
|
||||
- `rb8001/app/services/slack/coldmail_service.py`의 confirm 경로는 이미 `/api/v1/update`를 사용합니다.
|
||||
- `rb8001/app/services/slack/coldmail_service.py`의 IR 분석 경로는 `loading_ts`를 확보하지만, 완료/실패 시 갱신에 재사용하지 않습니다.
|
||||
- 오늘 실제 Slack 쓰레드에서도 `로빙 중…`가 완료 후 사라지지 않고 남아 있음을 확인했습니다.
|
||||
|
||||
## 8. 앞으로 되어야 하는 상태
|
||||
- 콜드메일 IR 분석도 confirm 흐름과 같은 방식으로 로딩 메시지를 갱신해야 합니다.
|
||||
- 성공 시에는 로딩 메시지가 완료 상태를 표현하고, 실패 시에는 오류 상태를 표현해야 합니다.
|
||||
- IR 분석 쓰레드에서 `로빙 중…`가 상시 잔류하는 현재 UX는 닫혀야 합니다.
|
||||
|
||||
## 9. 디버그 결론
|
||||
- 이 이슈는 `skill-slack 기능 부족`이 아니라 `IR 분석 로딩 메시지 update 경로 누락` 버그입니다.
|
||||
- 문제의 본질은 삭제 기능 부재가 아니라, 이미 존재하는 `update` 기능을 IR 흐름이 사용하지 않는 상태 차이입니다.
|
||||
- 다음 문서는 이 로딩 메시지를 어떤 내용으로 갱신할지와 성공/실패 UX를 어떻게 고정할지 결정하면 됩니다.
|
||||
@ -16,3 +16,5 @@ tags: [debug, journey, documentation, index]
|
||||
|
||||
- [콜드메일 IR 분석이 첫 번째 PDF를 잘못 선택하는 상태](./260313_coldmail_ir_분석대상_오선택_디버그.md)
|
||||
- 상태: `closed (fixed)`
|
||||
- [콜드메일 IR 분석 로딩 메시지가 완료 후 갱신되지 않는 상태](./260313_coldmail_ir_로딩메시지_미갱신_디버그.md)
|
||||
- 상태: `open`
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user