[FIX] ApiGatewayHandler send 오류 해결

[JungYoonShin]

Related Issue 🚀

• closed [FIX] ApiGatewayHandler send 오류 해결 #24

Work Description ✏️

• ApiGatewayHandler에서 REGISTER와 CANCEL 액션에서만 platform을 필수로 검증하고, SEND와 SEND_ALL 액션에서는 platform을 선택적으로 처리하도록 수정하였습니다!!

PR Point 📸

[coderabbitai]

Summary by CodeRabbit

• 버그 수정

  • API 게이트웨이 요청 처리 시 특정 작업 타입에 따라 플랫폼 필드가 선택적으로 처리되도록 개선되었습니다.

• 리팩토링

  • 요청 헤더 처리 로직을 최적화하여 안정성을 향상시켰습니다.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Walkthrough

RegisterHeaderDto를 RequestHeaderDto로 이름 변경하고, ApiGatewayRequestDto의 헤더 파라미터 타입을 업데이트했습니다. ApiGatewayHandler에서 platform 필드를 REGISTER 또는 CANCEL 액션에만 설정하도록 조건부 처리를 추가했습니다.

Changes

Cohort / File(s)	변경 사항
DTO 타입 이름 변경 src/main/java/com/sopt/push/dto/RequestHeaderDto.java	RegisterHeaderDto → RequestHeaderDto로 클래스 이름 변경 (필드 유지: transactionId, service, platform, action)
요청 DTO 파라미터 업데이트 src/main/java/com/sopt/push/dto/ApiGatewayRequestDto.java	레코드 파라미터 타입 변경: header 파라미터를 RegisterHeaderDto → RequestHeaderDto로 업데이트
헤더 생성 로직 수정 src/main/java/com/sopt/push/lambda/ApiGatewayHandler.java	extractRequest 메서드에서 RequestHeaderDto 객체 생성으로 변경, platform 필드를 REGISTER/CANCEL 액션에만 설정하도록 조건부 처리 추가 (다른 액션은 null)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• sung-silver

Poem

타입의 이름을 요청으로 바꾸니, 🐰
등록만 필요한 플랫폼을 간결히,
핸들러가 현명하게 판단하네요.
깔끔한 변화, 버그도 사라져! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	PR 제목은 ApiGatewayHandler의 send 오류 해결이라는 주요 변경 사항을 명확하게 요약하고 있으며, 코드 변경 내용과 일치합니다.
Description check	✅ Passed	PR 설명에서 Related Issue, Work Description 섹션이 채워져 있으나 PR Point 섹션은 비어있어 일부 미완성 상태입니다.
Linked Issues check	✅ Passed	PR 변경 사항이 링크된 이슈 #24의 요구사항을 충족합니다: REGISTER/CANCEL은 platform 필수, SEND/SEND_ALL은 선택적 처리로 구현되었습니다.
Out of Scope Changes check	✅ Passed	모든 변경사항이 이슈 #24의 범위 내에 있습니다: DTO 리네이밍과 액션별 platform 검증 로직 수정이 목표 달성을 위한 필요한 변경입니다.

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/main/java/com/sopt/push/dto/RequestHeaderDto.java (1)

7-8: 리네이밍은 적절하나 nullable 필드에 대한 문서화가 필요합니다.

RegisterHeaderDto에서 RequestHeaderDto로의 이름 변경은 이제 등록뿐만 아니라 여러 액션에서 사용되므로 더 적절합니다.

그러나 platform 필드가 이제 일부 액션(SEND, SEND_ALL)에서는 null일 수 있는데, 이에 대한 문서화나 @Nullable 어노테이션이 없습니다. 향후 개발자가 이 DTO를 사용할 때 혼란을 줄 수 있습니다.

📝 nullable 필드 문서화 제안

+import javax.annotation.Nullable;
+
+/**
+ * @param platform REGISTER 및 CANCEL 액션에서는 필수, SEND 및 SEND_ALL 액션에서는 null
+ */
 public record RequestHeaderDto(
-    String transactionId, Services service, Platform platform, Actions action) {}
+    String transactionId, Services service, @Nullable Platform platform, Actions action) {}

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5540c4b and 4d5e30a.

📒 Files selected for processing (3)

• src/main/java/com/sopt/push/dto/ApiGatewayRequestDto.java
• src/main/java/com/sopt/push/dto/RequestHeaderDto.java
• src/main/java/com/sopt/push/lambda/ApiGatewayHandler.java

🔇 Additional comments (4)

src/main/java/com/sopt/push/dto/ApiGatewayRequestDto.java (1)

5-5: 타입 업데이트가 올바르게 적용되었습니다.

RequestHeaderDto로의 타입 변경이 일관성 있게 적용되었습니다.

src/main/java/com/sopt/push/lambda/ApiGatewayHandler.java (3)

27-27: Import 업데이트가 올바르게 적용되었습니다.

RequestHeaderDto로의 import 변경이 일관성 있게 적용되었습니다.

---

117-121: 조건부 platform 파싱 로직이 PR 목표를 올바르게 구현했습니다.

REGISTER와 CANCEL 액션에서만 platform을 파싱하도록 하여, SEND 및 SEND_ALL 액션에서 platform이 필수가 아니도록 수정한 것은 PR 목표와 일치합니다.

Platform.fromValue 메서드는 null 또는 blank 값에 대해 "Platform value cannot be null or blank" 메시지와 함께 BusinessException을 명시적으로 발생시킵니다. 따라서 REGISTER 또는 CANCEL 액션에서 platformStr 헤더가 누락되거나 null인 경우 적절한 예외가 발생하며, 별도의 null 체크는 필요하지 않습니다.

---

123-124: 헤더 생성 로직이 올바르게 구현되었습니다.

조건부로 설정된 platform 값(REGISTER/CANCEL의 경우 non-null, SEND/SEND_ALL의 경우 null)을 사용하여 RequestHeaderDto를 생성하는 것은 올바릅니다.

request.header().platform()에 접근하는 handleRegister (line 137)와 handleCancel (line 166)은 main handler의 switch 문 (lines 75-79)을 통해 action이 REGISTER 또는 CANCEL일 때만 호출되므로, 해당 메서드들이 실행될 때 platform은 항상 null이 아닙니다. extractRequest의 조건문 (lines 119-121)과 main handler의 라우팅 로직이 자연스럽게 일치하므로 NPE 위험은 없습니다.

[seoyeonjin]

저번에 조건 2개 이상이면 따로 변수로 빼기로 했던 거 맞나영 ?? 컨벤션으로 정했는지 궁금합니당

[seoyeonjin]

좋습니당 !!