refactor : 예외 처리 강화 및 클래스 분리 #106
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thezz9
requested review from
Kimminu7,
NCookies,
chat26666,
minjee2758 and
pokerbearkr
Walkthrough이 변경사항은 제출 및 채점 로직을 대폭 리팩토링하여, Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SubmissionService
participant JudgementService
participant Judge0Client
participant EventService
User->>SubmissionService: submitCodeStream(msg)
SubmissionService->>JudgementService: publishInitTestcases(ctx)
JudgementService->>EventService: publish InitTestcaseList
SubmissionService->>JudgementService: runTestcases(ctx)
loop for each testcase
JudgementService->>Judge0Client: submitAndGetToken(request)
Judge0Client-->>JudgementService: token
JudgementService->>Judge0Client: pollUntilDone(token)
Judge0Client-->>JudgementService: JudgeResult
JudgementService->>EventService: publish TestcaseResult
end
JudgementService->>JudgementService: awaitAllTestcases()
SubmissionService->>JudgementService: finalizeAndPublish(ctx)
JudgementService->>EventService: publish FinalResult, ProblemSolve
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
src/main/resources/templates/submit-test.html (1)
110-110: 테스트 케이스 추적 로직 완성 필요
receivedCasesSet이 추가되어 테스트 케이스 sequence ID를 추적하고 있지만, 실제로는 활용되지 않고 있습니다. 중복 처리 방지나 진행 상황 표시 등의 기능을 구현하면 더 유용할 것입니다.다음과 같이 개선할 수 있습니다:
function handleCase(data) { const d = document.getElementById(`slot-${data.seqId}`); if (!d) return; + + // 중복 처리 방지 + if (receivedCases.has(data.seqId)) { + console.warn(`Duplicate case result for seqId: ${data.seqId}`); + return; + } + d.className = data.isPassed ? 'slot passed' : 'slot failed'; d.textContent = `[${data.seqId}] ${data.message} (${data.executionTime}s, ${data.memoryUsage}KB)`; receivedCases.add(data.seqId); + + // 진행 상황 표시 + console.log(`Progress: ${receivedCases.size} cases received`); }Also applies to: 118-118
src/main/java/org/ezcode/codetest/application/submission/dto/event/payload/InitTestcaseListPayload.java (1)
20-23: SubmissionContext 통합이 적절합니다.
ProblemInfo에서SubmissionContext로 변경하여 데이터 접근을 통합한 것은 좋은 개선입니다.다만
ctx.getTestcases().get(seq - 1)에서getTestcases()리스트 크기와getTestcaseCount()가 항상 일치하는지 확인이 필요합니다. 방어적 프로그래밍을 위해 경계 검사를 추가하는 것을 고려해보시기 바랍니다.public static List<InitTestcaseListPayload> from(SubmissionContext ctx) { + List<Testcase> testcases = ctx.getTestcases(); + if (testcases.size() != ctx.getTestcaseCount()) { + throw new IllegalStateException("테스트케이스 개수 불일치"); + } return IntStream.rangeClosed(1, ctx.getTestcaseCount()) .mapToObj(seq -> { - Testcase tc = ctx.getTestcases().get(seq - 1); + Testcase tc = testcases.get(seq - 1); return new InitTestcaseListPayload( seq, tc.getInput(), tc.getOutput(), "채점 중" ); }) .toList(); }src/main/java/org/ezcode/codetest/infrastructure/openai/OpenAIReviewClient.java (1)
74-74: 포맷 검증 실패 예외에 컨텍스트 추가를 고려해보세요.현재 예외 생성 시 단순히 예외 코드만 전달하고 있습니다. 디버깅을 위해 추가 정보를 포함하면 좋겠습니다.
- exceptionNotifier.notifyException("requestReview", new CodeReviewException(CodeReviewExceptionCode.REVIEW_INVALID_FORMAT)); + var formatException = new CodeReviewException( + CodeReviewExceptionCode.REVIEW_INVALID_FORMAT, + String.format("포맷 검증 %d회 시도 실패 [isCorrect=%s]", maxAttempts, reviewPayload.isCorrect()) + ); + exceptionNotifier.notifyException("requestReview", formatException);src/main/java/org/ezcode/codetest/infrastructure/event/publisher/DiscordNotifier.java (1)
55-63: 알 수 없는 예외에 대한 추가 정보 포함을 고려해보세요.현재는 예외 메시지만 포함하고 있는데, 디버깅을 위해 예외 타입이나 원인 정보도 포함하면 좋겠습니다.
} else { description = "채점 중 알 수 없는 예외 발생"; exceptionDetail = """ • 성공 여부: false • 상태코드: 500 - • 메시지: %s - """.formatted(Optional.ofNullable(t.getMessage()).orElse("No message")); + • 예외 타입: %s + • 메시지: %s + • 원인: %s + """.formatted( + t.getClass().getSimpleName(), + Optional.ofNullable(t.getMessage()).orElse("No message"), + Optional.ofNullable(t.getCause()).map(Throwable::getMessage).orElse("No cause") + ); }src/main/java/org/ezcode/codetest/application/submission/service/JudgementService.java (2)
54-56: 타임아웃을 설정 가능하도록 만드는 것을 고려해보세요.현재 100초로 하드코딩된 타임아웃은 문제 난이도나 테스트케이스 수에 따라 조정이 필요할 수 있습니다.
+ @Value("${judgement.testcase.timeout:100}") + private int testcaseTimeoutSeconds; + public void runTestcases(SubmissionContext ctx) throws InterruptedException { IntStream.rangeClosed(1, ctx.getTestcaseCount()) .forEach(seqId -> runTestcaseAsync(seqId, ctx)); - if (!ctx.latch().await(100, TimeUnit.SECONDS)) { + if (!ctx.latch().await(testcaseTimeoutSeconds, TimeUnit.SECONDS)) { throw new SubmissionException(SubmissionExceptionCode.TESTCASE_TIMEOUT); } }
74-74: 스레드 로깅 레벨을 조정하는 것을 고려해보세요.모든 테스트케이스마다 INFO 레벨로 로깅하는 것은 프로덕션 환경에서 너무 많은 로그를 생성할 수 있습니다.
- log.info("[Judge RUN] Thread = {}", Thread.currentThread().getName()); + log.debug("[Judge RUN] Thread = {}", Thread.currentThread().getName());
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (24)
src/main/java/org/ezcode/codetest/application/submission/dto/event/payload/InitTestcaseListPayload.java(2 hunks)src/main/java/org/ezcode/codetest/application/submission/dto/event/payload/TestcaseResultPayload.java(1 hunks)src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java(2 hunks)src/main/java/org/ezcode/codetest/application/submission/dto/response/compile/ExecutionResultResponse.java(1 hunks)src/main/java/org/ezcode/codetest/application/submission/model/SubmissionContext.java(2 hunks)src/main/java/org/ezcode/codetest/application/submission/port/ExceptionNotifier.java(1 hunks)src/main/java/org/ezcode/codetest/application/submission/service/JudgementService.java(1 hunks)src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java(3 hunks)src/main/java/org/ezcode/codetest/domain/problem/model/ProblemInfo.java(1 hunks)src/main/java/org/ezcode/codetest/domain/submission/dto/AnswerEvaluation.java(1 hunks)src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java(3 hunks)src/main/java/org/ezcode/codetest/domain/submission/model/SubmissionAggregator.java(1 hunks)src/main/java/org/ezcode/codetest/domain/submission/model/TestcaseEvaluationInput.java(2 hunks)src/main/java/org/ezcode/codetest/domain/submission/repository/UserProblemResultRepository.java(1 hunks)src/main/java/org/ezcode/codetest/domain/submission/service/SubmissionDomainService.java(4 hunks)src/main/java/org/ezcode/codetest/infrastructure/event/listener/GameLevelUpListener.java(2 hunks)src/main/java/org/ezcode/codetest/infrastructure/event/listener/SubmissionEventListener.java(2 hunks)src/main/java/org/ezcode/codetest/infrastructure/event/publisher/DiscordNotifier.java(2 hunks)src/main/java/org/ezcode/codetest/infrastructure/event/publisher/RedisJudgeQueueProducer.java(1 hunks)src/main/java/org/ezcode/codetest/infrastructure/judge0/Judge0Client.java(2 hunks)src/main/java/org/ezcode/codetest/infrastructure/judge0/Judge0ResponseMapper.java(2 hunks)src/main/java/org/ezcode/codetest/infrastructure/openai/OpenAIReviewClient.java(4 hunks)src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/submission/impl/UserProblemResultRepositoryImpl.java(1 hunks)src/main/resources/templates/submit-test.html(1 hunks)
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
Learnt from: chat26666
PR: ezcode-my/backend#37
File: src/main/java/org/ezcode/codetest/infrastructure/elasticsearch/repository/ProblemElasticsearchRepositoryDsl.java:10-10
Timestamp: 2025-06-06T19:56:27.759Z
Learning: When user chat26666 mentions that code was implemented in a previous PR but explanation was missing, they may submit a follow-up PR just to add documentation/explanation without the actual implementation code.
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java:5-9
Timestamp: 2025-06-06T07:52:58.941Z
Learning: CodeCompileRequest 레코드의 필드명(source_code, language_id)은 Java camelCase 컨벤션 대신 snake_case를 사용하는데, 이는 Judge0 API의 반환 값 형식에 맞추기 위한 의도적인 설계 결정이다.
Learnt from: thezz9
PR: ezcode-my/backend#75
File: src/main/java/org/ezcode/codetest/application/submission/aop/CodeReviewLockAspect.java:25-41
Timestamp: 2025-06-19T06:37:57.845Z
Learning: User thezz9 tends to skip validation for scenarios they consider unlikely to occur, but is willing to implement defensive programming practices when suggested for code robustness.
src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/submission/impl/UserProblemResultRepositoryImpl.java (1)
Learnt from: chat26666
PR: ezcode-my/backend#64
File: src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/game/EncounterChoiceRepositoryImpl.java:0-0
Timestamp: 2025-06-15T04:37:29.231Z
Learning: EncounterChoiceRepositoryImpl in src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/game/EncounterChoiceRepositoryImpl.java is intentionally a skeleton implementation that is work-in-progress and will be completed later.
src/main/resources/templates/submit-test.html (1)
Learnt from: thezz9
PR: ezcode-my/backend#73
File: src/main/resources/templates/submit-test.html:135-135
Timestamp: 2025-06-18T11:41:58.457Z
Learning: src/main/resources/templates/submit-test.html 파일은 테스트용 파일로, isCorrect 값의 하드코딩은 의도적이며 사용자가 UI 요소를 통해 정답/오답 상태를 선택할 수 있도록 개선 예정입니다.
src/main/java/org/ezcode/codetest/domain/submission/repository/UserProblemResultRepository.java (1)
Learnt from: chat26666
PR: ezcode-my/backend#64
File: src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/game/EncounterChoiceRepositoryImpl.java:0-0
Timestamp: 2025-06-15T04:37:29.231Z
Learning: EncounterChoiceRepositoryImpl in src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/game/EncounterChoiceRepositoryImpl.java is intentionally a skeleton implementation that is work-in-progress and will be completed later.
src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java (1)
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java:5-9
Timestamp: 2025-06-06T07:52:58.941Z
Learning: CodeCompileRequest 레코드의 필드명(source_code, language_id)은 Java camelCase 컨벤션 대신 snake_case를 사용하는데, 이는 Judge0 API의 반환 값 형식에 맞추기 위한 의도적인 설계 결정이다.
src/main/java/org/ezcode/codetest/infrastructure/event/listener/GameLevelUpListener.java (1)
Learnt from: chat26666
PR: ezcode-my/backend#67
File: src/main/java/org/ezcode/codetest/domain/game/service/CharacterEquipService.java:26-34
Timestamp: 2025-06-16T16:07:34.354Z
Learning: 이 프로젝트에서는 UseCase 레벨에서 트랜잭션 경계를 관리하므로, 도메인 서비스 클래스들(예: CharacterEquipService)에는 @Transactional 어노테이션이 필요하지 않습니다. 트랜잭션은 UseCase에서 열리므로 데이터 일관성이 보장됩니다.
src/main/java/org/ezcode/codetest/domain/submission/model/TestcaseEvaluationInput.java (2)
Learnt from: thezz9
PR: ezcode-my/backend#30
File: src/main/java/org/ezcode/codetest/domain/problem/service/SubmissionDomainService.java:24-33
Timestamp: 2025-06-04T13:12:28.354Z
Learning: The submission evaluation system is currently in testing phase, so hardcoded expected output values like "12" are intentionally used for testing purposes rather than being a production issue.
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java:47-58
Timestamp: 2025-06-06T07:59:41.806Z
Learning: SubmissionData.withAggregatedStats() 메서드에서 testCaseList는 상위 프로세스(base() 메서드의 problemInfo.testcaseList())에서 이미 null 체크가 처리되어 오므로 추가적인 null 체크가 불필요함
src/main/java/org/ezcode/codetest/infrastructure/openai/OpenAIReviewClient.java (2)
Learnt from: thezz9
PR: ezcode-my/backend#75
File: src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java:142-147
Timestamp: 2025-06-19T07:00:53.895Z
Learning: SubmissionService.getCodeReview() 메서드에서 토큰 차감을 리뷰 요청 전에 수행하는 이유: OpenAI 서버 장애보다 유저 토큰 부족 상황이 더 빈번하므로, 확률이 높은 실패 케이스를 먼저 체크하여 불필요한 처리를 방지함. OpenAI 서버 장애 시에는 OpenAIClient에서 트랜잭션 롤백으로 토큰 복원이 처리됨.
Learnt from: thezz9
PR: ezcode-my/backend#73
File: src/main/java/org/ezcode/codetest/infrastructure/openai/OpenAIReviewClient.java:52-64
Timestamp: 2025-06-18T11:42:03.701Z
Learning: OpenAI API 클라이언트에서는 두 가지 재시도 전략을 사용한다: 1) WebClient의 retryWhen은 네트워크/HTTP 에러 및 타임아웃에 대한 재시도, 2) 외부 for 루프는 API 응답 포맷 검증 실패에 대한 재시도. 이는 서로 다른 실패 상황을 처리하는 독립적인 메커니즘이다.
src/main/java/org/ezcode/codetest/application/submission/dto/event/payload/InitTestcaseListPayload.java (1)
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java:47-58
Timestamp: 2025-06-06T07:59:41.806Z
Learning: SubmissionData.withAggregatedStats() 메서드에서 testCaseList는 상위 프로세스(base() 메서드의 problemInfo.testcaseList())에서 이미 null 체크가 처리되어 오므로 추가적인 null 체크가 불필요함
src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java (1)
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java:47-58
Timestamp: 2025-06-06T07:59:41.806Z
Learning: SubmissionData.withAggregatedStats() 메서드에서 testCaseList는 상위 프로세스(base() 메서드의 problemInfo.testcaseList())에서 이미 null 체크가 처리되어 오므로 추가적인 null 체크가 불필요함
src/main/java/org/ezcode/codetest/domain/submission/service/SubmissionDomainService.java (5)
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java:47-58
Timestamp: 2025-06-06T07:59:41.806Z
Learning: SubmissionData.withAggregatedStats() 메서드에서 testCaseList는 상위 프로세스(base() 메서드의 problemInfo.testcaseList())에서 이미 null 체크가 처리되어 오므로 추가적인 null 체크가 불필요함
Learnt from: thezz9
PR: ezcode-my/backend#30
File: src/main/java/org/ezcode/codetest/domain/problem/service/SubmissionDomainService.java:24-33
Timestamp: 2025-06-04T13:12:28.354Z
Learning: The submission evaluation system is currently in testing phase, so hardcoded expected output values like "12" are intentionally used for testing purposes rather than being a production issue.
Learnt from: chat26666
PR: ezcode-my/backend#31
File: src/main/java/org/ezcode/codetest/domain/problem/service/ProblemDomainService.java:25-27
Timestamp: 2025-06-04T15:11:19.343Z
Learning: In ProblemDomainService, when saving problems to both database and Elasticsearch, maintain transactional consistency by allowing rollback if either save operation fails. Data integrity between DB and ES is prioritized over availability - if Elasticsearch save fails, the entire transaction should roll back to prevent data inconsistency.
Learnt from: chat26666
PR: ezcode-my/backend#64
File: src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/game/EncounterChoiceRepositoryImpl.java:0-0
Timestamp: 2025-06-15T04:37:29.231Z
Learning: EncounterChoiceRepositoryImpl in src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/game/EncounterChoiceRepositoryImpl.java is intentionally a skeleton implementation that is work-in-progress and will be completed later.
Learnt from: chat26666
PR: ezcode-my/backend#67
File: src/main/java/org/ezcode/codetest/domain/game/service/CharacterEquipService.java:26-34
Timestamp: 2025-06-16T16:07:34.354Z
Learning: 이 프로젝트에서는 UseCase 레벨에서 트랜잭션 경계를 관리하므로, 도메인 서비스 클래스들(예: CharacterEquipService)에는 @Transactional 어노테이션이 필요하지 않습니다. 트랜잭션은 UseCase에서 열리므로 데이터 일관성이 보장됩니다.
src/main/java/org/ezcode/codetest/infrastructure/judge0/Judge0Client.java (1)
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java:5-9
Timestamp: 2025-06-06T07:52:58.941Z
Learning: CodeCompileRequest 레코드의 필드명(source_code, language_id)은 Java camelCase 컨벤션 대신 snake_case를 사용하는데, 이는 Judge0 API의 반환 값 형식에 맞추기 위한 의도적인 설계 결정이다.
src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java (1)
Learnt from: thezz9
PR: ezcode-my/backend#75
File: src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java:142-147
Timestamp: 2025-06-19T07:00:53.895Z
Learning: SubmissionService.getCodeReview() 메서드에서 토큰 차감을 리뷰 요청 전에 수행하는 이유: OpenAI 서버 장애보다 유저 토큰 부족 상황이 더 빈번하므로, 확률이 높은 실패 케이스를 먼저 체크하여 불필요한 처리를 방지함. OpenAI 서버 장애 시에는 OpenAIClient에서 트랜잭션 롤백으로 토큰 복원이 처리됨.
🧬 Code Graph Analysis (1)
src/main/java/org/ezcode/codetest/application/submission/model/SubmissionContext.java (1)
src/main/java/org/ezcode/codetest/domain/submission/model/SubmissionAggregator.java (1)
SubmissionAggregator(3-24)
🔇 Additional comments (31)
src/main/java/org/ezcode/codetest/domain/problem/model/ProblemInfo.java (1)
15-17: 타입 변경으로 인한 호환성 확인 필요
getTimeLimit()메서드의 반환 타입이double에서long으로 변경되었습니다. 이 변경으로 인해 기존 코드에서 소수점 시간 제한값을 사용하던 부분에 영향을 줄 수 있습니다.다음 스크립트를 실행하여 타입 변경의 영향을 확인해주세요:
#!/bin/bash # Description: ProblemInfo.getTimeLimit() 사용처를 찾아 타입 변경 영향 확인 # getTimeLimit() 메서드 사용처 검색 rg -A 3 -B 1 "getTimeLimit\(\)" --type java # double 타입으로 시간 제한을 처리하는 코드 검색 rg -A 3 -B 1 "double.*[Tt]ime[Ll]imit" --type java # Judge0나 외부 API와 관련된 시간 제한 처리 코드 검색 rg -A 5 -B 2 "judge0|Judge0.*time|time.*judge" --type javasrc/main/java/org/ezcode/codetest/application/submission/port/ExceptionNotifier.java (1)
5-5: 인터페이스 개선사항 승인메서드 시그니처가
sendEmbed에서notifyException으로 변경되고, 파라미터가Throwable객체를 직접 받도록 개선되었습니다. 이는 더 표준적이고 유연한 예외 알림 방식입니다.구현체들이 새로운 인터페이스를 올바르게 구현했는지 확인해주세요:
#!/bin/bash # Description: ExceptionNotifier 인터페이스 구현체들의 업데이트 상태 확인 # ExceptionNotifier 구현체 검색 rg -A 10 "implements ExceptionNotifier" --type java # 이전 sendEmbed 메서드 사용이 남아있는지 확인 rg "sendEmbed" --type java # notifyException 메서드 구현 확인 rg -A 5 "notifyException.*String.*Throwable" --type javasrc/main/java/org/ezcode/codetest/infrastructure/event/publisher/RedisJudgeQueueProducer.java (1)
21-21: 아키텍처 변경을 반영한 로깅 개선SSE에서 WebSocket으로의 통신 방식 변경을 반영하여 로그 메시지가 적절하게 업데이트되었습니다.
sessionKey라는 명명도 더 명확하고 일관성 있습니다.src/main/java/org/ezcode/codetest/domain/submission/dto/AnswerEvaluation.java (1)
16-16: 코드 스타일 개선 승인Record 클래스에서 불필요한
this.참조를 제거하여 코드가 더 간결해졌습니다. Java record의 관례를 잘 따르는 개선사항입니다.src/main/java/org/ezcode/codetest/infrastructure/judge0/Judge0ResponseMapper.java (1)
55-58: ```shell
#!/bin/bashSearch for Base64 encoding method in CodeCompileRequest
rg -n "encodeBase64" --type java -A5
Fallback: search for Base64.getEncoder usage across the repo
rg -n "Base64.getEncoder" -n --type java -A5
</details> <details> <summary>src/main/java/org/ezcode/codetest/application/submission/dto/response/compile/ExecutionResultResponse.java (1)</summary> `22-33`: **컴파일 오류 팩토리 메서드 구현이 적절합니다** 정적 팩토리 메서드 패턴을 올바르게 사용하여 컴파일 오류 상황을 표현하고 있습니다. 오류 상태에 맞는 적절한 기본값들을 설정하고, status id 6과 의미있는 설명을 사용하여 Judge0 API 규격에 맞는 응답을 생성합니다. </details> <details> <summary>src/main/java/org/ezcode/codetest/infrastructure/persistence/repository/submission/impl/UserProblemResultRepositoryImpl.java (1)</summary> `31-33`: **메서드 시그니처 변경이 적절합니다** 반환 타입을 `void`로 변경한 것은 JPA 엔티티의 in-place 수정 패턴에 맞는 적절한 변경입니다. 엔티티가 영속성 컨텍스트에서 관리되므로 `updateResult()` 호출 후 별도의 반환이 불필요하며, API를 단순화하는 좋은 리팩토링입니다. </details> <details> <summary>src/main/java/org/ezcode/codetest/domain/submission/model/SubmissionAggregator.java (1)</summary> `11-15`: **매개변수 캡슐화 리팩토링이 적절합니다** `accumulate` 메서드의 매개변수를 개별 값들에서 `TestcaseEvaluationInput` 객체로 변경한 것은 좋은 리팩토링입니다. 관련된 데이터를 하나의 객체로 캡슐화하여 매개변수 수를 줄이고 유지보수성을 향상시켰습니다. </details> <details> <summary>src/main/java/org/ezcode/codetest/infrastructure/event/listener/SubmissionEventListener.java (1)</summary> `39-39`: 다른 이벤트 리스너 애노테이션 적용 상태를 정확히 확인하기 위해 아래 스크립트를 실행해주세요. ```shell #!/bin/bash # SubmissionEventListener 내 모든 @EventListener/@TransactionalEventListener 확인 rg -n '@EventListener|@TransactionalEventListener' -g 'src/main/java/org/ezcode/codetest/infrastructure/event/listener/SubmissionEventListener.java'src/main/java/org/ezcode/codetest/domain/submission/repository/UserProblemResultRepository.java (1)
16-16: 메서드 시그니처 일관성 추가 확인을 위해 아래 스크립트로 저장소 전체에서updateUserProblemResult호출 및 선언 위치를 검색해 주세요.#!/bin/bash # 저장소 전체에서 updateUserProblemResult 선언 및 호출 위치 검색 rg --color=never -n 'updateUserProblemResult' .src/main/java/org/ezcode/codetest/application/submission/dto/event/payload/TestcaseResultPayload.java (1)
20-23: 메서드 시그니처 단순화가 우수합니다.
AnswerEvaluation객체 의존성을 제거하고boolean isPassed파라미터를 직접 받도록 변경한 것은 결합도를 낮추고 API를 단순화하는 좋은 개선입니다.src/main/java/org/ezcode/codetest/infrastructure/event/listener/GameLevelUpListener.java (1)
23-24: 트랜잭션 이벤트 리스너 적용이 일관성 있습니다.
SubmissionEventListener와 동일하게@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)를 적용하여 이벤트 처리의 일관성을 유지했습니다.
@Transactional(propagation = Propagation.REQUIRES_NEW)와의 조합으로 독립적인 트랜잭션에서 레벨업 로직이 처리되어 메인 트랜잭션과 분리되는 것도 적절합니다.src/main/java/org/ezcode/codetest/infrastructure/openai/OpenAIReviewClient.java (1)
62-67: 예외 알림 통합이 잘 구현되었습니다.예외 알림이 트랜잭션 롤백 전에 수행되어 알림 실패가 트랜잭션에 영향을 주지 않도록 설계된 점이 좋습니다.
src/main/java/org/ezcode/codetest/domain/submission/model/TestcaseEvaluationInput.java (1)
20-48: 리소스 제한 정보 추가 및 평가 로직 캡슐화가 잘 구현되었습니다.테스트케이스 평가에 필요한 모든 정보를 하나의 레코드에 모아 응집도를 높였고, 평가 메서드들이 명확하게 구현되었습니다. 특히
isCorrect()메서드에서strip()을 사용하여 공백 처리를 적절히 한 점이 좋습니다.src/main/java/org/ezcode/codetest/domain/submission/dto/SubmissionData.java (1)
34-71: SubmissionContext를 중심으로 한 리팩토링이 잘 수행되었습니다.복잡한 파라미터 전달을 SubmissionContext로 통합하여 메서드 시그니처가 단순해졌고, 데이터 변환 로직이 명확해졌습니다. 정적 팩토리 메서드 패턴을 일관되게 사용한 점도 좋습니다.
src/main/java/org/ezcode/codetest/infrastructure/event/publisher/DiscordNotifier.java (1)
32-66: 예외 타입별 처리 로직이 잘 구현되었습니다.예외 객체를 직접 받아 타입별로 적절한 메시지를 생성하는 방식이 좋습니다.
Optional을 사용한 null 안전성 처리도 적절합니다.src/main/java/org/ezcode/codetest/application/submission/service/JudgementService.java (2)
84-87: 원자적 알림 플래그를 사용한 중복 알림 방지가 잘 구현되었습니다.
compareAndSet을 사용하여 동시성 환경에서도 한 번만 알림이 전송되도록 보장한 점이 좋습니다.
35-109: 채점 로직의 분리가 잘 수행되었습니다.SubmissionService에서 채점 관련 로직을 분리하여 단일 책임 원칙을 잘 준수했습니다. 비동기 처리, 이벤트 발행, 예외 처리가 체계적으로 구현되었습니다.
src/main/java/org/ezcode/codetest/domain/submission/service/SubmissionDomainService.java (5)
29-51: 메서드 시그니처 개선이 잘 되었습니다.
SubmissionContext를 사용하여 여러 파라미터를 하나로 통합한 것은 응집력 있는 리팩토링입니다. 도메인 로직도 올바르게 유지되고 있습니다.
53-68: 평가 로직 분리가 잘 되었습니다.평가 로직을 private 메서드로 분리하고
TestcaseEvaluationInput을 활용한 것이 좋습니다.SubmissionContext의 atomic 연산을 사용하여 스레드 안전성도 보장됩니다.
80-86: 평가 로직이 명확합니다.
TestcaseEvaluationInput의 새로운 메서드들을 활용하여 평가 로직을 깔끔하게 구현했습니다.
88-90: 통계 수집 로직이 개선되었습니다.
TestcaseEvaluationInput전체를 전달하여 캡슐화를 향상시켰습니다.
104-106: 메서드 시그니처가 적절하게 변경되었습니다.반환값이 사용되지 않는 경우 void로 변경한 것이 명확성을 높입니다.
src/main/java/org/ezcode/codetest/infrastructure/judge0/Judge0Client.java (3)
36-42: WebClient 설정이 적절합니다.반응형 프로그래밍을 위한 WebClient 초기화가 올바르게 구성되었습니다.
45-69: 반응형 구현이 잘 되었습니다.적절한 타임아웃(5초)과 재시도 전략(exponential backoff)이 설정되었고, 에러 처리도 명확합니다.
72-96: 반응형 폴링 로직이 잘 구현되었습니다.1초 간격 폴링과 BadRequest 처리가 적절합니다. 다만, 60초 타임아웃이 충분한지 확인이 필요합니다.
복잡한 코드나 큰 입력에 대해 Judge0의 실행 시간이 60초를 초과할 가능성이 있는지 검토해 주세요.
src/main/java/org/ezcode/codetest/application/submission/model/SubmissionContext.java (2)
32-55: 도메인 데이터 통합이 잘 되었습니다.
SubmissionContext가 제출 처리에 필요한 모든 도메인 데이터를 캡슐화하여 응집력이 향상되었습니다.
89-127: Accessor 메서드들이 잘 구성되었습니다.필요한 데이터에 쉽게 접근할 수 있도록 명확한 메서드들이 제공됩니다.
src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java (3)
68-84: 책임 분리가 훌륭하게 이루어졌습니다.복잡한 채점 로직을
JudgementService로 위임하여 단일 책임 원칙을 준수하고 가독성을 크게 향상시켰습니다.
86-92: 컨텍스트 생성 로직이 깔끔합니다.필요한 도메인 데이터를 조회하고
SubmissionContext를 생성하는 로직이 명확하게 분리되었습니다.
51-51: 새로운 서비스 의존성이 적절히 추가되었습니다.
JudgementService를 통한 관심사 분리가 아키텍처를 개선했습니다.
Comment on lines
+24
to
+26
| private static String encodeBase64(String str) { | ||
| return Base64.getEncoder().encodeToString(str.getBytes(StandardCharsets.UTF_8)); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
🧩 Verification correct
Base64 인코딩 메서드가 미사용 상태입니다
encodeBase64 메서드가 정의되어 있지만 같은 클래스의 of 팩토리 메서드에서 사용되지 않고 있습니다. Judge0 API로 전송하는 데이터가 Base64 인코딩이 필요한지 확인이 필요합니다.
Judge0 API 요구사항을 확인하기 위해 다음 스크립트를 실행해주세요:
만약 인코딩이 필요하다면 팩토리 메서드에서 다음과 같이 적용해야 합니다:
public static CodeCompileRequest of(int seqId, SubmissionContext ctx) {
return new CodeCompileRequest(
- ctx.getSourceCode(),
+ encodeBase64(ctx.getSourceCode()),
ctx.getJudge0Id(),
- ctx.getInput(seqId));
+ encodeBase64(ctx.getInput(seqId)));
}🏁 Script executed:
#!/bin/bash
# Description: CodeCompileRequest에서 Base64 인코딩 사용 여부 및 Judge0Client에서의 처리 확인
# Judge0Client에서 CodeCompileRequest 사용 방식 확인
rg -A 10 -B 5 "CodeCompileRequest" --type java
# Base64 인코딩 관련 코드 검색
rg -A 5 "encodeBase64|Base64" --type javaLength of output: 15868
Base64 인코딩 메서드가 미사용 상태입니다
encodeBase64 메서드가 정의되어 있지만 같은 클래스의 of 팩토리 메서드에서 사용되지 않고 있습니다. Judge0 API로 전송하는 데이터가 Base64 인코딩이 필요한지 확인이 필요합니다.
Judge0 API 요구사항을 확인하기 위해 다음 스크립트를 실행해주세요:
#!/bin/bash
# Description: CodeCompileRequest에서 Base64 인코딩 사용 여부 및 Judge0Client에서의 처리 확인
# Judge0Client에서 CodeCompileRequest 사용 방식 확인
rg -A 10 -B 5 "CodeCompileRequest" --type java
# Base64 인코딩 관련 코드 검색
rg -A 5 "encodeBase64|Base64" --type java만약 인코딩이 필요하다면 팩토리 메서드에서 다음과 같이 적용해야 합니다:
public static CodeCompileRequest of(int seqId, SubmissionContext ctx) {
return new CodeCompileRequest(
- ctx.getSourceCode(),
+ encodeBase64(ctx.getSourceCode()),
ctx.getJudge0Id(),
- ctx.getInput(seqId));
+ encodeBase64(ctx.getInput(seqId)));
}🤖 Prompt for AI Agents
In
src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java
around lines 24 to 26, the encodeBase64 method is defined but not used anywhere
in the class, including the of factory method. Verify if the Judge0 API requires
the code or input data to be Base64 encoded before sending. If encoding is
required, modify the of factory method to apply encodeBase64 to the relevant
fields before constructing the CodeCompileRequest instance. If encoding is not
needed, consider removing the unused encodeBase64 method to clean up the code.
Collaborator
Author
There was a problem hiding this comment.
아 이거 관련해서 이슈가 좀 있었어서 이것저것 해보던 건데 안 지웠네 다음 PR에 지울게
There was a problem hiding this comment.
@thezz9 네, 이해했습니다! 이슈 해결 과정에서 여러 시도를 해보시느라 남겨둔 코드군요.
혹시 이 정리 작업을 추적하기 위해 follow-up 이슈를 생성해드릴까요? 아니면 다음 PR에서 바로 처리하실 계획이시면 그대로 두셔도 됩니다.
실험적인 코드가 남아있는 것은 충분히 이해할 수 있는 상황입니다! 👍
🧠 Learnings used
Learnt from: thezz9
PR: ezcode-my/backend#36
File: src/main/java/org/ezcode/codetest/application/submission/dto/request/compile/CodeCompileRequest.java:5-9
Timestamp: 2025-06-06T07:52:58.941Z
Learning: CodeCompileRequest 레코드의 필드명(source_code, language_id)은 Java camelCase 컨벤션 대신 snake_case를 사용하는데, 이는 Judge0 API의 반환 값 형식에 맞추기 위한 의도적인 설계 결정이다.
Learnt from: thezz9
PR: ezcode-my/backend#75
File: src/main/java/org/ezcode/codetest/application/submission/aop/CodeReviewLockAspect.java:25-41
Timestamp: 2025-06-19T06:37:57.845Z
Learning: User thezz9 tends to skip validation for scenarios they consider unlikely to occur, but is willing to implement defensive programming practices when suggested for code robustness.
Learnt from: chat26666
PR: ezcode-my/backend#37
File: src/main/java/org/ezcode/codetest/infrastructure/elasticsearch/repository/ProblemElasticsearchRepositoryDsl.java:10-10
Timestamp: 2025-06-06T19:56:27.759Z
Learning: When user chat26666 mentions that code was implemented in a previous PR but explanation was missing, they may submit a follow-up PR just to add documentation/explanation without the actual implementation code.
Comment on lines
+105
to
+111
| public String getInput(int seqId) { | ||
| return getTestcases().get(seqId - 1).getInput(); | ||
| } | ||
|
|
||
| public String getExpectedOutput(int seqId) { | ||
| return getTestcases().get(seqId - 1).getOutput(); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
배열 경계 검사를 추가하는 것이 좋겠습니다.
잘못된 seqId 값이 전달될 경우 IndexOutOfBoundsException이 발생할 수 있습니다.
다음과 같이 경계 검사를 추가하세요:
public String getInput(int seqId) {
+ if (seqId < 1 || seqId > getTestcaseCount()) {
+ throw new IllegalArgumentException("Invalid seqId: " + seqId);
+ }
return getTestcases().get(seqId - 1).getInput();
}
public String getExpectedOutput(int seqId) {
+ if (seqId < 1 || seqId > getTestcaseCount()) {
+ throw new IllegalArgumentException("Invalid seqId: " + seqId);
+ }
return getTestcases().get(seqId - 1).getOutput();
}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In
src/main/java/org/ezcode/codetest/application/submission/model/SubmissionContext.java
around lines 105 to 111, the methods getInput and getExpectedOutput access the
testcases list without checking if seqId is within valid bounds, which can cause
IndexOutOfBoundsException. Add boundary checks to ensure seqId is greater than 0
and less than or equal to the size of the testcases list before accessing it. If
seqId is out of range, handle it appropriately, such as returning null or
throwing a custom exception.
Collaborator
Author
There was a problem hiding this comment.
밖에서 스트림 돌려서 오는 거라 잘못된 값이 전달될 일은 없는데 방어 로직 추가해서 나쁠 건 없다는 말이지?
There was a problem hiding this comment.
@thezz9 맞습니다! 현재 구현에서는 외부 스트림에서 순차적으로 오는 값이라 잘못된 seqId가 전달될 가능성이 낮지만, 방어 로직을 추가하는 것이 여러 면에서 도움이 됩니다:
방어 로직의 장점:
- 미래 변경사항 대비: 코드가 수정되면서 호출 패턴이 바뀔 수 있음
- 디버깅 편의성: 문제 발생 시 명확한 에러 메시지로 원인 파악이 쉬움
- 코드 자체 문서화: 메서드가 기대하는 입력 범위를 명시적으로 표현
- Fail-fast 원칙: 문제를 빨리 발견하고 처리
특히 현재 PR에서 코드 구조를 개선하고 예외 처리를 강화하는 작업을 하고 계시니, 이런 방어 로직도 전체적인 코드 견고성 향상에 부합하는 것 같습니다.
추가하실지는 전체적인 코드 정책과 우선순위에 따라 결정하시면 될 것 같습니다!
🧠 Learnings used
Learnt from: thezz9
PR: ezcode-my/backend#30
File: src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java:44-46
Timestamp: 2025-06-04T13:12:17.636Z
Learning: SubmissionService에서 "2 10" 입력값과 "12" 기대출력이 하드코딩되어 있는 것은 테스트 단계의 의도적인 구현이며, 추후 Problem 엔티티의 실제 테스트케이스로 대체 예정입니다.
Learnt from: thezz9
PR: ezcode-my/backend#75
File: src/main/java/org/ezcode/codetest/application/submission/aop/CodeReviewLockAspect.java:25-41
Timestamp: 2025-06-19T06:37:57.845Z
Learning: User thezz9 tends to skip validation for scenarios they consider unlikely to occur, but is willing to implement defensive programming practices when suggested for code robustness.
Learnt from: chat26666
PR: ezcode-my/backend#37
File: src/main/java/org/ezcode/codetest/infrastructure/elasticsearch/repository/ProblemElasticsearchRepositoryDsl.java:10-10
Timestamp: 2025-06-06T19:56:27.759Z
Learning: When user chat26666 mentions that code was implemented in a previous PR but explanation was missing, they may submit a follow-up PR just to add documentation/explanation without the actual implementation code.
There was a problem hiding this comment.
@thezz9 알겠습니다! 필요하시면 언제든 말씀해 주세요. 현재 PR의 예외 처리 강화 작업 잘 진행되고 있는 것 같습니다. 👍
🧠 Learnings used
Learnt from: thezz9
PR: ezcode-my/backend#75
File: src/main/java/org/ezcode/codetest/application/submission/aop/CodeReviewLockAspect.java:25-41
Timestamp: 2025-06-19T06:37:57.845Z
Learning: User thezz9 tends to skip validation for scenarios they consider unlikely to occur, but is willing to implement defensive programming practices when suggested for code robustness.
Learnt from: thezz9
PR: ezcode-my/backend#30
File: src/main/java/org/ezcode/codetest/application/submission/service/SubmissionService.java:44-46
Timestamp: 2025-06-04T13:12:17.636Z
Learning: SubmissionService에서 "2 10" 입력값과 "12" 기대출력이 하드코딩되어 있는 것은 테스트 단계의 의도적인 구현이며, 추후 Problem 엔티티의 실제 테스트케이스로 대체 예정입니다.
Learnt from: thezz9
PR: ezcode-my/backend#30
File: src/main/java/org/ezcode/codetest/domain/problem/model/dto/SubmissionData.java:42-53
Timestamp: 2025-06-04T13:12:16.729Z
Learning: 사용자 thezz9는 개발 시 기능적 정확성을 먼저 달성한 후 세부 리팩터링을 나중에 하는 접근 방식을 선호한다. 테스트 단계에서는 하드코딩된 값도 허용한다.
Learnt from: chat26666
PR: ezcode-my/backend#37
File: src/main/java/org/ezcode/codetest/infrastructure/elasticsearch/repository/ProblemElasticsearchRepositoryDsl.java:10-10
Timestamp: 2025-06-06T19:56:27.759Z
Learning: When user chat26666 mentions that code was implemented in a previous PR but explanation was missing, they may submit a follow-up PR just to add documentation/explanation without the actual implementation code.
pokerbearkr
approved these changes
Jun 26, 2025
Kimminu7
approved these changes
Jun 26, 2025
minjee2758
approved these changes
Jun 26, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
작업 내용
Summary by CodeRabbit
신규 기능
버그 수정
리팩터링
스타일
문서화
기타