Skip to content

prod : 환불 후속 처리 (결제 엔티티 제거) #294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
polyglot-k merged 4 commits into from
Aug 10, 2025
Merged

prod : 환불 후속 처리 (결제 엔티티 제거) #294

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ee528cf
refactor: develop 쿠기 secure false전환
jbh010204 Aug 10, 2025
195f97e
feat: add deleteByExamApplicationId method to PaymentJpaRepository an…
polyglot-k Aug 10, 2025
3bc3eef
Merge branch 'develop' of https://github.com/mosu-dev/mosu-server int…
polyglot-k Aug 10, 2025
b7d6fb9
MOSU refactor: set secure flag to true for development cookies
wlgns12370 Aug 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion src/main/java/life/mosu/mosuserver/application/refund/tx/RefundTxEventListener.java
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
package life.mosu.mosuserver.application.refund.tx;

import life.mosu.mosuserver.application.refund.support.RefundQuotaSyncService;
import life.mosu.mosuserver.domain.payment.repository.PaymentJpaRepository;
import life.mosu.mosuserver.global.tx.TxFailureHandler;
import life.mosu.mosuserver.infra.notify.dto.luna.LunaNotificationEvent;
import life.mosu.mosuserver.infra.notify.dto.luna.LunaNotificationStatus;
Expand All @@ -19,6 +20,7 @@ public class RefundTxEventListener {
private final TxFailureHandler<RefundContext> refundFailureHandler;
private final NotifyEventPublisher notifier;
private final RefundQuotaSyncService quotaSyncService;
private final PaymentJpaRepository paymentJpaRepository;

@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
public void afterRollbackHandler(RefundTxEvent event) {
Expand All @@ -33,7 +35,7 @@ public void afterCommitHandler(RefundTxEvent event) {
RefundContext ctx = event.getContext();
quotaSyncService.sync(ctx.examId());
log.info("[AFTER_COMMIT] 환불 성공 후 알림톡 발송 시작: orderId={}", ctx.transactionKey());

paymentJpaRepository.deleteByExamApplicationId(ctx.examApplicationId());
Copy link

@gemini-code-assist gemini-code-assist bot Aug 10, 2025

Choose a reason for hiding this comment

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

high

The operations within afterCommitHandler are not atomic. If paymentJpaRepository.deleteByExamApplicationId() fails, the quotaSyncService.sync() operation that already succeeded will not be rolled back. This can leave the system in an inconsistent state where the application quota is decreased, but the corresponding payment record still exists.

To prevent this, you should implement a compensation mechanism by catching exceptions from the delete operation and calling a compensating action on quotaSyncService to revert the quota change.

Additionally, please see my comment on PaymentJpaRepository.java regarding potential issues with the deleteByExamApplicationId method itself (hard vs. soft delete and performance).

        try {
            paymentJpaRepository.deleteByExamApplicationId(ctx.examApplicationId());
        } catch (Exception e) {
            log.error("Failed to delete payment for examApplicationId: {}. Rolling back quota.", ctx.examApplicationId(), e);
            quotaSyncService.rollbackQuota(ctx.examId());
            throw e; // Rethrow to ensure failure is propagated and logged by the event listener mechanism.
        }

sendNotification(ctx.userId(), ctx.examApplicationId());
}

Expand Down
4 changes: 3 additions & 1 deletion src/main/java/life/mosu/mosuserver/domain/payment/repository/PaymentJpaRepository.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,15 +2,17 @@

import java.time.LocalDateTime;
import java.util.List;
import life.mosu.mosuserver.domain.payment.projection.PaymentWithLunchProjection;
import life.mosu.mosuserver.domain.payment.entity.PaymentJpaEntity;
import life.mosu.mosuserver.domain.payment.projection.PaymentWithLunchProjection;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;

public interface PaymentJpaRepository extends JpaRepository<PaymentJpaEntity, Long>,
PaymentJpaRepositoryCustom {

void deleteByExamApplicationId(Long examApplicationId);
Copy link

@gemini-code-assist gemini-code-assist bot Aug 10, 2025

Choose a reason for hiding this comment

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

critical

There are two concerns with this method:

  1. Hard Delete vs. Soft Delete: This derived delete query will execute a direct DELETE statement. If PaymentJpaEntity is configured for soft-deletes (as its parent BaseDeleteEntity might imply), this method will perform a hard delete, bypassing the soft-delete logic (e.g., @SQLDelete). If soft deletion is intended, this is a critical issue. You may need a custom query to perform an UPDATE for a soft delete.

  2. Performance: The exam_application_id column in the payment table does not have an index. A DELETE operation on this column will result in a full table scan, which can be very slow and resource-intensive on a large table. Please consider adding an index to exam_application_id in the PaymentJpaEntity definition.


// TODO:인덱스 처리 필요(풀스캔 위험)
boolean existsByOrderId(String orderId);

Expand Down