fix(feed): 서포터 중복 수락 방지 및 accumulateFunding null 안전성 보완

[hoTan35]

관련 이슈

Closes #89

문제

OFFER/REQUEST 피드에서 작성자가 이미 서포터를 수락했음에도 두 번째 서포터를 수락할 수 있었고, 이 경우 accumulateFunding에서 Integer 필드가 DB에서 null로 로딩돼 500 NPE 발생.

변경 내용

FeedItem.java

• canAcceptMore() 추가: confirmedPartnerCount >= 1이면 false → OFFER/REQUEST 모두 서포터 1명 상한
• accumulateFunding() null 안전 처리: @Builder.Default가 Hibernate 리플렉션 로딩 시 미적용되는 문제 보완

FeedItemService.java

• acceptApplication()에서 작성자 확인 직후 canAcceptMore() 체크 삽입
• 상한 초과 시 IllegalStateException → GlobalExceptionHandler가 400 반환 (기존 500 → 400)

테스트 시나리오

1. OFFER 피드에 서포터 1명 수락 → 정상 Spot 전환
2. 동일 피드에 두 번째 서포터 수락 시도 → 400 이미 서포터 모집이 완료된 피드입니다.
3. REQUEST 피드 동일하게 적용

Summary by CodeRabbit

• Refactor
  • Improved code maintainability and clarity of internal feed logic by replacing hardcoded values with a named constant and expanding documentation for the feed acceptance mechanism.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4e83c128-d204-4069-88a3-8ac94b1eb796

📥 Commits

Reviewing files that changed from the base of the PR and between 7cdf3f6 and fd785a0.

📒 Files selected for processing (1)

• capstone-domain/src/main/java/backend/feed/entity/FeedItem.java

---

📝 Walkthrough

Walkthrough

FeedItem now defines a private static constant MAX_SUPPORTERS_PER_FEED set to 1 to replace a hardcoded limit check in the canAcceptMore() method. The method's Javadoc is expanded to clarify that the UI maxParticipants parameter does not control acceptance decisions, isolating acceptance logic from UI constraints.

Changes

Feed Item Acceptance Limit

Layer / File(s)	Summary
Feed acceptance limit constant and canAcceptMore() refinement capstone-domain/src/main/java/backend/feed/entity/FeedItem.java	MAX_SUPPORTERS_PER_FEED constant replaces the hardcoded acceptance limit value. canAcceptMore() method logic remains functionally identical but now reads the limit from the named constant. Javadoc is expanded to document that UI maxParticipants is independent of the internal acceptance-limit enforcement.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

• ThonApple
• ca5tlechan

Poem

🐰 A magic number hops away,
Becomes a constant, here to stay,
MAX_SUPPORTERS_PER_FEED now shines,
One supporter per feed, the rule defines,
Clean code bounds with rabbit delight! ✨

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/feed-supporter-cap

---

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.}

[hoTan35]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[ca5tlechan]

❌ Changes Requested — Blocking 1건

✅ 좋은 점

• accumulateFunding() null 안전성 — fundedAmount / confirmedPartnerCount null 체크 정상 적용 ✅
• 비관적 락 획득 후 canAcceptMore() 체크 순서 올바름 ✅

---

🔴 Blocking — canAcceptMore() maxParticipants 무시, 1 하드코딩

FeedItem에 maxParticipants 필드가 존재하지만 canAcceptMore()는 이를 무시하고 confirmed < 1로 고정합니다.

maxParticipants=3으로 생성된 피드는 1명이 수락된 순간 canAcceptMore() = false가 되어, 나머지 2개 슬롯을 채울 수 없습니다.

수정안:

public boolean canAcceptMore() {
    int confirmed = this.confirmedPartnerCount != null ? this.confirmedPartnerCount : 0;
    int max = this.maxParticipants != null ? this.maxParticipants : 1;
    return confirmed < max;
}

만약 제품 정책상 서포터는 항상 1명으로 고정이라면, 이를 명시적으로 상수화하고 maxParticipants 필드와의 관계를 주석으로 설명해 주세요.

[hoTan35]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[hoTan35]

리뷰 반영 (ca5tlechan)

정책 확인: 서포터는 OFFER/REQUEST 모두 1명으로 고정하는 것이 현재 서비스 정책입니다.

변경 내용:

• 매직 넘버 1 → MAX_SUPPORTERS_PER_FEED = 1 상수로 추출
• maxParticipants 필드와의 관계를 주석으로 명시
  • maxParticipants: 프론트 UI 모집 정원 표시용
  • 수락 상한 판단에는 사용하지 않음 (정책상 항상 1명)

private static final int MAX_SUPPORTERS_PER_FEED = 1;

public boolean canAcceptMore() {
    int confirmed = this.confirmedPartnerCount != null ? this.confirmedPartnerCount : 0;
    return confirmed < MAX_SUPPORTERS_PER_FEED;
}

[ca5tlechan]

✅ Approve — Blocking 수정 확인

✅ 수정 확인

• MAX_SUPPORTERS_PER_FEED = 1 상수 추출 — 매직 넘버 제거 ✅
• Javadoc 명시 — maxParticipants는 프론트 UI 표시용, 수락 상한 판단에는 MAX_SUPPORTERS_PER_FEED 사용함을 명확히 구분 ✅
• accumulateFunding() null 안전성 유지 ✅
• 비관적 락 획득 후 canAcceptMore() 체크 순서 올바름 ✅