Skip to content

GitHub App 동시성 문제 개선 TECH SPEC#2

Open
quino0627 wants to merge 1 commit intomainfrom
codex/docs-improve-github-app
Open

GitHub App 동시성 문제 개선 TECH SPEC#2
quino0627 wants to merge 1 commit intomainfrom
codex/docs-improve-github-app

Conversation

@quino0627
Copy link
Copy Markdown

@quino0627 quino0627 commented Mar 19, 2026

Summary

  • add docs/improve-github-app with current architecture, concurrency, and batching design docs
  • add phased implementation plans for async ingress, recovery/reconciliation, and batching rollout
  • document Redis-based ordering strategy, operational guardrails, and review-driven caveats

Testing

  • git diff --check -- docs/improve-github-app

Summary by CodeRabbit

  • Documentation
    • GitHub App 웹훅의 현재 아키텍처 분석 문서 추가
    • 주문/동시성(배달 중복, 큐/스트림, 분산 락, Redis 기반 상태) 설계 문서 및 Phase‑1 구현 계획 추가
    • 이벤트 배칭·요약 정책(Phase‑3) 및 운영·검증 가이드 문서 추가
    • 목표 아키텍처·리뷰용 흐름 요약 문서 추가
    • Phase‑2 복구·anchor fallback·운영 가시성 및 회복 플랜 문서 추가
    • 개선 작업 전체를 정리한 README 및 체크리스트 추가

@channeltalk
Copy link
Copy Markdown

channeltalk bot commented Mar 19, 2026

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 19, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

cht-app-github 개선 문서 세트가 추가되어 현재 아키텍처, webhook 인그레스의 문제점, Redis 기반 ingress/큐/락/aggregate 상태 설계, 이벤트 배칭 전략 및 Phase 1–3 로드맵과 단계별 구현·운영 계획을 문서화합니다.

Changes

Cohort / File(s) Summary
개선 문서 인덱스 및 개요
docs/improve-github-app/README.md
개선 트랙(동시성·정렬, 이벤트 배칭) 소개, 현재 제약 및 권장 다음 단계 요약을 추가함.
현재 아키텍처 및 문제점
docs/improve-github-app/01-current-architecture.md
기존 cht-app-github의 webhook·앱 함수 제어 흐름, root 메시지 생성·앵커 방식, 실패 모드(중복 root, 루트 미발견, delivery idempotency 부재, 클라이언트 풀 레이스, FindAppInstallationID 버그 등)를 문서화함.
동시성·정렬 설계
docs/improve-github-app/02-ordering-and-concurrency.md
Redis 기반 delivery dedup(SETNX 스타일), 스트림 큐, per-aggregate 분산 락, aggregate 상태 모델(state:agg:...), ingress→worker 흐름, crash-safety(보류중 anchor 상태) 및 구현 변경 사항 및 롤아웃 계획을 제안함.
이벤트 배칭 설계
docs/improve-github-app/03-event-batching.md
배칭 원칙(중요 상태 보존, 원문 링크, terminal 즉시성 등), 배치 유형(root-init/collaboration/code-update/terminal), 윈도우·flush 규칙, 충돌 처리 및 운영 지표/오픈 이슈 정리.
타깃 아키텍처 및 책임 분리
docs/improve-github-app/04-target-architecture.md
Clean Architecture 관점의 레이어·포트·인프라 분리, ingress/worker/reconciler/BatchPolicy 책임과 전체 데이터 흐름을 제시함.
리뷰용 문제·Redis 흐름 요약
docs/improve-github-app/05-review-problem-redis-flow.md
관찰된 실패 모드, 핵심 불변식(배달 idempotency, per-aggregate 직렬화, 단일 루트 등) 및 Phase별 Redis 키·흐름(ingress, worker, reconciler) 예시를 제시함.
로드맵(요약)
docs/improve-github-app/10-phase-roadmap.md
3단계 로드맵(정합성 안정화 → 복구·운영 강화 → 배칭·소음 감소)과 단계별 전제조건·검증 지표 및 롤아웃 권장절차를 정의함.
Phase 1 구현 계획
docs/improve-github-app/11-phase-1-implementation-plan.md
/hook 인그레스에서 요청 바이트 보존·시그니처 검증·Redis dedup·스트림 적재, Envelope/aggregate 규약, worker/lock/state 모델, pending anchor 복구, 메트릭·테스트 체크리스트 등 상세 실행 계획.
Phase 2 구현 계획
docs/improve-github-app/12-phase-2-implementation-plan.md
앵커 마커 포맷·검증, 댓글 페이징·복구 CLI, dirty-aggregate 리콘실리에이션 설계, Prometheus 지표 스키마 및 운영 검증 절차를 정의.
Phase 3 구현 계획
docs/improve-github-app/13-phase-3-implementation-plan.md
ActivityItem/Processor 모델, BatchPolicy 결정(즉시/배치/무효), 배치 충돌·flush 규칙, suppression·롤아웃 가이드 및 검증 방법을 상세화.

Sequence Diagram(s)

sequenceDiagram
  participant GitHub
  participant Ingress as "/hook/v1 (ingress)"
  participant Redis
  participant Worker
  participant LockStore as "lock:agg:{key}"
  participant ChannelTalk
  participant GitHubAPI as "GitHub API"

  GitHub->>Ingress: POST webhook (headers + raw payload)
  Ingress->>Ingress: verify signature, compute deliveryID
  Ingress->>Redis: SETNX dedup:delivery:{deliveryID}
  alt dedup reserved
    Ingress->>Redis: XADD stream:github-events <envelope>
    Ingress-->>GitHub: respond 200/202 (ack)
  else duplicate
    Ingress-->>GitHub: respond 200 (duplicate)
  end

  loop worker loop
    Worker->>Redis: XREAD/XCLAIM stream:github-events
    Worker->>Worker: compute canonical aggregateKey
    Worker->>LockStore: SET NX lock:agg:{aggregateKey}
    LockStore-->>Worker: lock acquired
    Worker->>Redis: HGET state:agg:{aggregateKey}
    alt root not present
      Worker->>ChannelTalk: create root message
      ChannelTalk-->>Worker: root_id
      Worker->>GitHubAPI: post anchor comment
      GitHubAPI-->>Worker: comment_id
      Worker->>Redis: HSET state:agg:{aggregateKey} (root_id, comment_id, status)
    else root exists
      Worker->>ChannelTalk: write/update message under root
    end
    Worker->>Redis: HSET state:agg:{aggregateKey} (progress), XACK stream
    Worker->>LockStore: DEL lock:agg:{aggregateKey}
  end
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 숲속 webhook 소포를 물고,
레디스 길에 발자국을 남겼네.
락을 걸고 이벤트를 모아,
하나의 루트로 조용히 엮었지.
버그는 도망가고 로그는 밝아지네. ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check ✅ Passed PR 제목이 'GitHub App 동시성 문제 개선 TECH SPEC'으로 변경 세트의 주요 내용(GitHub App 아키텍처, 동시성 제어, 배칭에 대한 설계 문서 추가)을 명확하게 요약하고 있습니다.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch codex/docs-improve-github-app

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/improve-github-app/11-phase-1-implementation-plan.md`:
- Line 3: Replace the actor-specific prefix "**For Claude:** REQUIRED SUB-SKILL:
Use superpowers:executing-plans to implement this plan task-by-task." with a
neutral, team-oriented instruction such as "REQUIRED SUB-SKILL: Use
superpowers:executing-plans to implement this plan task-by-task" or "Team note:
use superpowers:executing-plans to implement this plan task-by-task," removing
any mention of a specific executor; update the sentence in the document heading
that currently starts with "For Claude:" so the phrasing is repository-wide and
inclusive.

In `@docs/improve-github-app/12-phase-2-implementation-plan.md`:
- Line 3: Remove the agent-specific directive "For Claude: REQUIRED SUB-SKILL:
Use superpowers:executing-plans" and replace it with a neutral,
repository-agnostic instruction such as "Execute the plan task-by-task" or
"Perform tasks sequentially"; update the sentence containing "Use
superpowers:executing-plans" so it does not reference a specific agent or
special skill set and instead conveys the intended behavior in generic terms.

In `@docs/improve-github-app/13-phase-3-implementation-plan.md`:
- Line 13: The heading "Task 0: worker processing seam 정리" is using ### which
skips a level after H1; change that heading to use ## (i.e., prefix with two
hashes) or insert an appropriate intermediate H2 section above so the document's
heading levels increase by one step to satisfy MD001 and remove the markdownlint
warning for the "Task 0: worker processing seam 정리" heading.
- Line 3: 문서 본문에 남아있는 에이전트 전용 실행 지시문("For Claude: REQUIRED SUB-SKILL: Use
superpowers:executing-plans to implement this plan task-by-task")는 협업 문서에 적절하지
않으니 본문에서 삭제하고 해당 문구를 별도의 에이전트 전용 실행 지침 섹션으로 이전하거나 저장소 공통 실행 가이드(예:
CONTRIBUTING/AGENT_GUIDELINES)에 일반화하여 옮기고, 문서 본문에는 공개적으로 남겨도 무방한 대체 문구(예: "에이전트가
자동 실행을 필요로 하는 작업이 있습니다" 등)만 남기도록 수정하세요.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c731a24c-0157-46ee-bb3c-54b7105fd065

📥 Commits

Reviewing files that changed from the base of the PR and between 7ac4bc9 and c5c36fc.

📒 Files selected for processing (8)
  • docs/improve-github-app/01-current-architecture.md
  • docs/improve-github-app/02-ordering-and-concurrency.md
  • docs/improve-github-app/03-event-batching.md
  • docs/improve-github-app/10-phase-roadmap.md
  • docs/improve-github-app/11-phase-1-implementation-plan.md
  • docs/improve-github-app/12-phase-2-implementation-plan.md
  • docs/improve-github-app/13-phase-3-implementation-plan.md
  • docs/improve-github-app/README.md

@quino0627 quino0627 changed the title docs: add github app improvement design and phase plans GitHub App 동시성 문제 개선 Mar 24, 2026
@quino0627 quino0627 changed the title GitHub App 동시성 문제 개선 GitHub App 동시성 문제 개선 TECH SPEC Mar 25, 2026
@quino0627 quino0627 requested a review from Clsan March 25, 2026 15:31
@quino0627 quino0627 force-pushed the codex/docs-improve-github-app branch from cfc41d3 to 3cfddbc Compare March 25, 2026 15:32
@quino0627 quino0627 requested a review from leesea14 March 27, 2026 05:34
Copy link
Copy Markdown

@leesea14 leesea14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

전체적으로 설계가 잘 정리되어 있고 Goals/Non-goals 명시가 특히 좋았습니다.

1. ValKey distributed lock vs Kafka partition-by-subject

현재 Kafka 도입 전환 중인 상황을 감안하면, subject key로 partition을 나누는 방식도 worker 경쟁 문제를 구조적으로 해결할 수 있는 선택지인 것 같습니다. out-of-order 문제는 어느 쪽이든 state machine이 필요하긴 하지만, lock TTL 관련 엣지케이스를 구조적으로 없앨 수 있다는 점에서 고려해보셨는지 궁금합니다. ValKey lock 방식을 선택한 이유가 있으면 문서에 남겨두면 좋지 않을까요?!

2. Lock TTL 만료 시 first root wins forever invariant

lock:subject:{subjectKey} TTL이 30s인데, downstream write가 느릴 경우 lock이 만료된 뒤 다른 worker가 같은 subject를 처리할 수 있습니다. 이때 두 worker가 각각 root가 없다고 판단해 subject:{subjectKey}에 rootMessageId를 write하려 하면, first root wins forever invariant를 ValKey 레벨에서 어떻게 보장하는지 궁금합니다. SET NX 또는 optimistic locking 같은 보호가 필요하지 않을까요?!

3. GitHub App 서비스 규모 대비 설계 복잡도

실제 관찰된 문제를 해결하는 설계라는 건 이해하는데, GitHub App의 서비스 특성상 subject당 동시 webhook 빈도가 얼마나 되는지 궁금합니다. ValKey stream + distributed lock + state machine + Phase 1/2 순차 rollout은 상당한 운영 복잡도를 수반하는데, 현재 관찰된 문제의 규모가 이 복잡도를 감수할 만한 수준인지, 혹은 더 단순한 접근(예: 단일 worker + dedup만)으로 먼저 검증하고 점진적으로 복잡도를 추가하는 방향은 고려해보셨는지 여쭤봐도 될까요?!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants