chore(release): dev → main 승격 차단 사유 추적 - #586
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2fb097482c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: APP_AUTH_SECRET_LIFECYCLE_MODE | ||
| value: "disabled" |
There was a problem hiding this comment.
운영 배포에 새 보안 설정을 추가했지만 NODE_ENV=production은 설정하지 않았습니다. 확인한 .github/workflows/deploy-eks-gateway.yml은 이 manifest를 api-server 운영 배포에 그대로 적용하며, 현재 상태에서는 LoginSecuritySettings.from_environment()가 development 기본값을 사용해 독립 fingerprint keyring 없이 기동하고 require_connector_test_security_ready()도 production 전용 HMAC 검증을 우회합니다. 운영에서 의도한 fail-closed 보안 경계를 적용하도록 이 env 블록에 NODE_ENV=production과 필수 production secret 참조를 추가해야 합니다.
Useful? React with 👍 / 👎.
| COPY apps/memory /app/apps/memory | ||
| COPY apps/workflow_engine /app/apps/workflow_engine |
There was a problem hiding this comment.
Gateway 이미지가 이제 apps/memory와 apps/workflow_engine 코드를 직접 포함하지만, 확인한 .github/workflows/deploy-eks-gateway.yml의 on.push.paths는 여전히 apps/gateway/**, apps/shared/**, docker/gateway/**만 감시합니다. 따라서 memory 또는 workflow engine만 변경한 main 커밋은 Gateway 이미지를 다시 빌드하지 않아, 운영 API가 같은 릴리스의 오래된 memory/model-routing 코드를 계속 실행하게 됩니다. 이미지에 포함되는 두 경로를 Gateway 배포 트리거에도 추가해야 합니다.
Useful? React with 👍 / 👎.
| beat_schedule={ | ||
| "security-alert-reconciliation": { | ||
| "task": "security_alert.reconcile", | ||
| "schedule": 60.0, | ||
| "options": {"queue": "log"}, |
There was a problem hiding this comment.
이 schedule은 Beat 프로세스가 실행되어야만 security_alert.reconcile, audit/notification outbox 처리, memory retention 및 knowledge recovery 작업을 큐에 발행합니다. 확인한 .github/workflows/deploy-eks-logger.yml과 infra/k8s/namespaces/default/ 전체에는 log Celery worker만 있고 Beat 리소스가 없으므로, 실제 EKS 배포에서는 이 주기 작업들이 한 번도 발행되지 않아 보안 경보와 audit 알림이 갱신되지 않고 실패한 ingestion/sync job도 복구되지 않습니다. Compose/Helm에 추가한 singleton Beat와 동등한 리소스를 EKS 배포 경로에도 포함해야 합니다.
Useful? React with 👍 / 👎.
| knowledgeWorker: | ||
| enabled: false | ||
| replicaCount: 2 |
There was a problem hiding this comment.
문서 등록 경로는 knowledge.document_ingestion.execute를 전용 knowledge 큐로 발행하지만 production Helm 값은 worker를 비활성화하며, 확인한 infra/k8s와 EKS deploy workflow 전체에도 apps.gateway.knowledge_worker를 실행하는 리소스가 없습니다. 따라서 운영에서 파일/API 문서를 추가하면 job과 Celery 메시지만 생성되고 소비자가 없어 계속 pending 상태로 남아 RAG 인덱싱 흐름이 완료되지 않습니다. Gateway migration 적용 후 이 worker를 활성화하는 배포 단계와 실제 EKS manifest를 함께 제공해야 합니다.
Useful? React with 👍 / 👎.
| valid_credentials = ( | ||
| db.query(LLMCredential).filter(LLMCredential.is_valid.is_(True)).all() | ||
| ) | ||
| return [LLMCredentialResponse.model_validate(c) for c in creds] | ||
| readable_credentials = [ | ||
| credential | ||
| for credential in valid_credentials | ||
| if has_llm_credential_permission(db, user_id, credential.id, "read") |
There was a problem hiding this comment.
GET /llm/credentials는 active organization header를 해석하지 않은 채 모든 유효 credential을 조회한 뒤 사용자의 read 권한만 검사합니다. 여러 organization을 관리하거나 양쪽에서 grant를 받은 사용자가 organization A를 선택해도 B의 credential 이름과 preview가 같은 관리 화면에 섞이고, 이를 선택한 뒤 A header로 permission 작업을 수행하면 404가 발생해 credential 관리 흐름이 깨집니다. LLMService.get_user_credentials에 검증된 active organization ID를 전달하고 쿼리와 permission 판정을 해당 organization으로 제한해야 합니다.
Useful? React with 👍 / 👎.
HyungminYoon1
changed the title
|
PR 목적을 즉시 승격에서
필수 검사 통과 전 강제 병합하지 않고, |
feat(security): Provider 실행 capability 경계 도입
refactor(memory): 공개 챗봇 대화 기록을 클라이언트 전달 방식으로 전환
feat: 쿠키 인증 API CSRF 경계 도입
perf(rag): 사전 계산 query embedding 기반 KB fan-out 병렬화
4 participants
목적
이 PR은
dev → main승격을 즉시 수행하기 위한 PR이 아니라, 승격을 제한하는 통합·CI 문제를 지속적으로 추적하는 게이트 PR입니다.dev의 최신 상태를main에 승격할 수 있는지 원격 CI로 확인합니다.dev가 갱신되면 PR head와 검사·승인 상태도 갱신되는 이동 기준선입니다.고정 보존 기준선
PR head와 별개로, 2026-07-20 당시 시연 가능 기준은 다음 ref에 고정했습니다.
2fb097482c5165ad9625262fc631af6a0f047a6drelease/demo-baseline-2026-07-20demo-baseline-2026-07-20두 ref에는 삭제 및 non-fast-forward 갱신 방지 규칙이 활성화되어 있습니다.
현재 확인된 승격 차단 사유
2026-07-20 PR head
2fb09748기준입니다.dev가 갱신되면 최신 CI 결과로 다시 판정합니다.gevent를 요구하지만 선택된 CI 환경에 설치되지 않음main...devdiff에서 Ruff 오류가 노출됨. import 정리뿐 아니라 undefined name 등 실제 오류 후보 포함/recheck-ci-control필요참고 실행:
담당 이슈
MBA-353은 일반 CI 실패 우회나 승인 정책 완화를 담당하지 않습니다.
운영 규칙
dev에 새 커밋이 병합되면 최신 head의 CI 결과로 체크리스트를 다시 갱신합니다.main승격 여부를 결정합니다.변경 유형
dev → main승격 게이트 추적보호 리소스·외부 실행 경계
dev에 병합된 변경의 통합 상태를 추적하는 PR입니다.