feat: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 #963

eun-byeol · 2025-01-29T10:24:36Z

🚩 연관 이슈

close #941

📝 작업 내용

1. 스케줄링 알림 발송 & fallback 전략

구체적인 로직은 노션에 정리해두었어요.
설명한 부분이지만 간단히 정리하면, 로직의 큰 그림은 이렇습니다.

약속시간 30분 전, 약속의 topic으로 스케줄링용 FCM 알림(eta scheduling notice)을 보냅니다.
안드는 해당 FCM 알림을 받으면, 약속시간+1분까지 10초마다 ETA API 요청을 예약합니다.

ETA API가 정상적으로 서버로 들어오지 않는 경우, 스케줄링용 FCM 알림을 device 별로 재전송합니다.
EtaService.findAllMateEtas()가 호출될 때마다, 레디스에 데이터를 갱신하는데,
그 전에 TTL 만료되면, 재전송 로직이 트리거됩니다.

핵심 로직을 시나리오로 테스트했습니다.

@DisplayName("정상 시나리오 : 스케줄링 그룹 알림 전송 -> ETA 요청 -> 스케줄링 개인 알림 재전송 X")
@TestFactory
Stream<DynamicTest> normalCase() {
    LocalDateTime now = TimeUtil.nowWithTrim();
    Meeting meeting = fixtureGenerator.generateMeeting(now.plusMinutes(30));
    Mate mate = fixtureGenerator.generateMate(meeting);
    fixtureGenerator.generateEta(mate);

    return Stream.of(
            dynamicTest("참가자들에게 ETA 스케줄링 알림을 전송한다.", () -> {
                etaSchedulingService.sendNotice(meeting);
                verify(noticeService).send(any(EtaSchedulingNotice.class), any(GroupMessage.class));
            }),
            dynamicTest("TTL 만료 전에 ETA api 요청이 오면, 스케줄링 알림이 재전송되지 않는다", () -> {
                Thread.sleep(ttlMs - 200);
                etaService.findAllMateEtas(dtoGenerator.generateMateEtaRequest(), mate);
                Thread.sleep(ttlMs - 200);
                verify(noticeService, never()).send(any(EtaSchedulingNotice.class), any(DirectMessage.class));
            })
    );
}

ttl 만료 직전까지 Thread.sleep()을 하지 않고 바로 eta api를 호출하도록 해도 되지만, 현실적인 딜레이(?)를 테스트코드에 담고자 했습니다.

@DisplayName("재발송 시나리오 : 스케줄링 그룹 알림 전송 -> ETA 요청 X -> 스케줄링 개인 알림 재전송")
@TestFactory
Stream<DynamicTest> resendCase() {
    LocalDateTime now = TimeUtil.nowWithTrim();
    Meeting meeting = fixtureGenerator.generateMeeting(now.plusMinutes(30));
    Mate mate = fixtureGenerator.generateMate(meeting);
    fixtureGenerator.generateEta(mate);

    return Stream.of(
            dynamicTest("참자가들에게 ETA 스케줄링 알림을 전송한다.", () -> {
                etaSchedulingService.sendNotice(meeting);
                verify(noticeService).send(any(EtaSchedulingNotice.class), any(GroupMessage.class));
            }),
            dynamicTest("TTL 만료 전에 ETA api 요청이 안 오면, 스케줄링 알림이 재전송된다.", () -> {
                Thread.sleep(ttlMs + 200);
                verify(noticeService).send(any(EtaSchedulingNotice.class), any(DirectMessage.class));
            })
    );
}

2. 스케줄링 등록 예외 처리

세 가지 예외 사항이 있습니다.

(처리) 서버 재배포로 스케줄링이 소실되는 경우 -> 서버가 다시 뜰 때, 스케줄링 재시도 로직 구현
(처리) 스케줄링 이후에 새로운 당일 약속이 생기는 경우 -> 당일 약속이면, 개별로 스케줄링
(처리X) 약속시간 30분 전 이후에 약속을 생성한 경우(ex. 약속시간: 10시, 생성시간: 9시 45분)
-> 최초 스케줄링 알림은 Meeting 생성 시점에 Topic 단위로 발송되기 때문에, 즉시 발송시 참여한 mate가 없어 아무도 스케줄링 알림을 받지 못합니다.
해당 경우 안드에서 예외처리를 할지(=스케줄링 알림을 기다리지 않고 바로 api 예약 진행), 백에서 예외처리할지 고민이 됩니다.
백에서 처리하려면 mate 생성 코드에서 스케줄링 로직이 침범하는데 코드 복잡성이 늘어나는 상황입니다. ‼️ 이에, 의견 부탁드립니다~!

3. [리팩터링] Notice 관련 로직 분리

이유: 기존 NotificationService에서는 알림 발송 시 Notification을 생성하는 로직과 Notification 생성하지 않는 로직이 혼재되어 있었어요. 확장성과 유지보수를 위해 도메인과 서비스를 나눴습니다.

Notice Type
- ETA_NOTICE
- ETA_SCHEDULING_NOTICE

Notification Type
- ENTRY
- DEPARTURE_REMINDER
- NUDGE
- LEAVE
- MEMBER_DELETION

4. [리팩터링] GroupMessage, DirectMessage 추상화

그룹대상이냐 개인이냐 하는 전송 대상만 다를 뿐, NoticeEvent는 같은 로직이라
AbstractMessage로 추상화하고 제네릭 사용하여 리팩터링했습니다.

    @Async("fcmAsyncExecutor")
    @EventListener
    public <T extends AbstractMessage> void sendNoticeMessage(NoticeEvent<T> noticeEvent) {
        fcmPushSender.sendMessage(noticeEvent.getMessage());
        log.info(
                "{} 공지 알림 전송 | 전송 시간 : {}",
                noticeEvent.getNotice().getType(),
                Instant.now().atZone(TimeUtil.KST_OFFSET)
        );
    }

NoticeType, Message 대상에 관계 없이 모두 같은 로직으로 처리할 수 있습니다.

🏞️ 스크린샷 (선택)

🗣️ 리뷰 요구사항 (선택)

🙇‍♀️ 약속시간 30분 전 이후에 약속을 생성한 경우, 예외처리 부분 의견 부탁드립니다.
최대한 레거시가 되지 않도록 해보았는데, 그럼에도 불구하고 로직이 깔끔하게 떨어지진 않아요.ㅠㅜ
리팩터링을 나눠서 하지 못해, PR 규모도 커서 최대한 설명을 남겼는데
궁금한 점이나 개선사항이 있으면 적극적으로 말씀해주세요!

github-actions · 2025-01-29T10:29:13Z

Test Results

67 files + 6 67 suites +6 12s ⏱️ ±0s
219 tests +15 215 ✅ +11 4 💤 +4 0 ❌ ±0
220 runs +15 216 ✅ +11 4 💤 +4 0 ❌ ±0

Results for commit 7d914f3. ± Comparison against base commit a89b34c.

This pull request removes 7 and adds 22 tests. Note that renamed tests count towards both.

com.ody.auth.JwtTokenProviderTest$validateAccessToken ‑ [1] accessToken=com.ody.auth.token.AccessToken@6f04acf2
com.ody.auth.JwtTokenProviderTest$validateAccessToken ‑ [2] accessToken=com.ody.auth.token.AccessToken@7298a2c1
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [1] date=2025-01-28, time=21:17:06.399922716, expected=false
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [2] date=2025-01-28, time=22:17:06.399941912, expected=true
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [3] date=2025-01-28, time=20:17:06.399932023, expected=false
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [4] date=2025-01-29, time=21:17:06.399922716, expected=true
com.ody.meeting.service.MeetingServiceTest ‑ 약속 생성 후 약속 시간 30분 전에 ETA 공지 알림이 예약된다.

com.ody.auth.JwtTokenProviderTest$validateAccessToken ‑ [1] accessToken=com.ody.auth.token.AccessToken@2190fd9f
com.ody.auth.JwtTokenProviderTest$validateAccessToken ‑ [2] accessToken=com.ody.auth.token.AccessToken@3e1eeaa5
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [1] date=2025-02-03, time=01:29:01.822704162, expected=false
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [2] date=2025-02-03, time=02:29:01.822729590, expected=true
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [3] date=2025-02-03, time=00:29:01.822716926, expected=false
com.ody.common.validator.FutureOrPresentDateTimeValidatorTest ‑ [4] date=2025-02-04, time=01:29:01.822704162, expected=true
com.ody.eta.service.EtaSchedulingKeyTest ‑ EtaSchedulingKey 구분자 형식이 맞지 않으면 예외가 발생한다.
com.ody.eta.service.EtaSchedulingKeyTest ‑ EtaSchedulingRedisTemplate key를 생성한다.
com.ody.eta.service.EtaSchedulingRedisTemplateTest ‑ 약속방 참여자 1명의 ETA 스케줄링 정보를 캐싱한다.
com.ody.eta.service.EtaSchedulingRedisTemplateTest ‑ 약속방 참여자 전원의 ETA 스케줄링 정보를 캐싱한다.
…

♻️ This comment has been updated with latest results.

github-actions · 2025-02-02T03:44:27Z

📝 Test Coverage Report

Overall Project	81.68% `-0.55%`	🍏
Files changed	93.6%	🍏

File	Coverage
PushEvent.java	100%	🍏
NoticeEvent.java	100%	🍏
EtaSchedulingKey.java	100%	🍏
GroupMessage.java	100%	🍏
AbstractMessage.java	100%	🍏
NoticeType.java	100%	🍏
EtaSchedulingNotice.java	100%	🍏
EtaNotice.java	100%	🍏
NotificationType.java	100%	🍏
RedisKeyExpiredListener.java	100%	🍏
NoticeService.java	100%	🍏
NotificationService.java	100%	🍏
EtaSchedulingService.java	99.27% `-0.73%`	🍏
EtaService.java	97.11%	🍏
MeetingService.java	95.74%	🍏
FcmPushSender.java	84.81%	🍏
EtaSchedulingRedisTemplate.java	83.72% `-16.28%`	🍏
FcmEventListener.java	76.34% `-11.83%`	❌
Notice.java	66.67% `-33.33%`	❌
DirectMessage.java	35.42%	🍏
RedisConfig.java	0% `-88%`	❌

mzeong

~~진행 상황 공유를 위해 중간 제출합니다~~
~~현재 8c0523c까지 확인했어요 (이 속도라면 목요일에는 끝날 거라고 예상(희망)합니다)~~
코드 리뷰 완료했습니다 ‼️ 조조의 노고가 느껴지는 코드였습니다 고생하셨습니다 🐥🐥

~~(커밋 단위로 확인한 후 전체 files changed 보는 순서로 코드 리뷰 진행하겠습니다!!~~
~~따라서 이미 수정된 과거 코드에 대해 리뷰를 남길 수도 있는데 리뷰 모두 완료하면 수정되어 있을 겁니다)~~

몇주째 기다리는 조조와 올리브 미안합니다 😓
이번 주말에는 조조가 꼭 코드 리뷰 반영 작업을 할 수 있기를..

mzeong · 2025-02-18T12:54:50Z

backend/src/main/java/com/ody/notification/domain/message/GroupMessage.java

-                .putData("meetingTime", meeting.getMeetingTime().format(FORMATTER))
+                .putData("type", etaSchedulingNotice.getType().name())
+                .putData("meetingId", String.valueOf(etaSchedulingNotice.getMeetingId()))
+                .putData("meetingTime", etaSchedulingNotice.getMeetingTime().format(FORMATTER))
                .setTopic(fcmTopic.getValue())
                .build();

        return new GroupMessage(message);
    }


[제안] Notice 타입마다 create 메서드를 하나씩 추가해야 한다는 점이 확장성 부분에서 아쉬운 것 같아 제안해봅니다

public static GroupMessage create(Notice notice, FcmTopic fcmTopic) { Message.Builder builder = Message.builder() .putData("type", notice.getType().name()) .setTopic(fcmTopic.getValue()); notice.getAdditionalData().forEach(builder::putData); return new GroupMessage(builder.build()); }

public class EtaSchedulingNotice extends Notice { private Long meetingId; private LocalDateTime meetingTime; @Override public Map<String, String> getAdditionalData() { return Map.of( "meetingId", String.valueOf(meetingId), "meetingTime", meetingTime.format(FORMATTER) ); } }

[사소한 의견]

확장성 측면에서는 제리의 제안에 동의해요. 그런데 그보다 저는 근본적으로 Notice라는 개념이 어떤 개념인지 통일하고 가는게 좋을 것 같다는 생각이 들었어요

저는 Notice라는 개념이 약속에 참여한 모든 유저에게 애플리케이션 상에서 실제로 전해지는 공지 느낌으로 생각했거든요. 그래서 Notice를 애플리케이션에서 공지가 전해지는 것과 무관하게 약속 topic을 대상으로 뿌리는 개념으로 추상화할건지, 아니면 실제 공지가 되는 내용인지의 기준을 세워야 할 것 같아요.

유저에게 전해지는가 ? -> 스케쥴링 로직은 안 전해짐 vs EtaNotice는 진짜 발송되는 공지용임

약속 내 참여한 모든 사용자에게 전해지는가? -> 이건 둘다 맞는 개념

2)번만으로 Notice에 대한 용어를 통일하고자 하면 제리가 제안한 구조로 해도 괜찮을 것 같고 만약 1번 까지 Notice의 개념 정의에 포함한다고 한다면 저는 Trigger로 Notice와 도메인을 구분하는 것도 좋을 것 같아요. 다만 리소스가 드는 일이니 Notice로 유지하는 방향이 나아보입니다!

TTL이 만료되면 디바이스 토큰을 이용해 개인에게 Notice를 하기 때문에 2번으로 정의하는 것도 부정확하지 않나요? 저는 로그에서 확인할 수 있는가를 기준으로 Notification, Notice를 나눴다고 이해했는데 조조의 정의가 궁금하네요

mzeong · 2025-02-18T13:42:13Z

backend/src/main/java/com/ody/eta/service/EtaSchedulingService.java

+    private boolean isPast(LocalDateTime dateTime) {
+        return TimeUtil.nowWithTrim().isAfter(dateTime);
+    }


[제안] isUpcoming, isPast 메서드는 TimeUtil이 가지고 있어도 좋을 것 같네요!

mzeong · 2025-02-18T13:54:06Z

backend/src/main/java/com/ody/meeting/repository/MeetingRepository.java

@@ -36,7 +36,7 @@ public interface MeetingRepository extends JpaRepository<Meeting, Long> {
            or (m.date = :endDate and m.time < :excludeEndTime)
            """
    )
-    List<Meeting> findAllWithInDateTimeRange(
+    List<Meeting> findAllWithInDateTimeRange( // StartDateTime >= TargetDateTime > EndDateTime


[제안] 🤔🤔 이름을 고민해보겠습니다.. findAllByDateTimeInClosedOpenRange으로 네이밍하는 건 어떤가요? 주석 없이도 [Start, End)를 드러낼 수 있을 것 같아요

mzeong · 2025-02-18T14:58:49Z

backend/src/test/java/com/ody/common/Fixture.java

@@ -63,10 +65,23 @@ public class Fixture {
            InviteCodeGenerator.generate()
    );

+    public static Meeting Meeting(long meetingId, LocalDateTime dateTime) {
+        return new Meeting(meetingId, "조조와 새해 떡국", dateTime.toLocalDate(), dateTime.toLocalTime(), TARGET_LOCATION, ODY_MEETING.getInviteCode(), false);


coli-geonwoo

저도 84e82cc까지 리뷰했습니다! 추후 커밋 따라가면서 계속 갱신할게요!

coli-geonwoo · 2025-02-18T18:06:10Z

backend/src/main/java/com/ody/notification/domain/message/GroupMessage.java

-                .putData("meetingTime", meeting.getMeetingTime().format(FORMATTER))
+                .putData("type", etaSchedulingNotice.getType().name())
+                .putData("meetingId", String.valueOf(etaSchedulingNotice.getMeetingId()))
+                .putData("meetingTime", etaSchedulingNotice.getMeetingTime().format(FORMATTER))
                .setTopic(fcmTopic.getValue())
                .build();

        return new GroupMessage(message);
    }


[사소한 의견]

확장성 측면에서는 제리의 제안에 동의해요. 그런데 그보다 저는 근본적으로 Notice라는 개념이 어떤 개념인지 통일하고 가는게 좋을 것 같다는 생각이 들었어요

저는 Notice라는 개념이 약속에 참여한 모든 유저에게 애플리케이션 상에서 실제로 전해지는 공지 느낌으로 생각했거든요. 그래서 Notice를 애플리케이션에서 공지가 전해지는 것과 무관하게 약속 topic을 대상으로 뿌리는 개념으로 추상화할건지, 아니면 실제 공지가 되는 내용인지의 기준을 세워야 할 것 같아요.

유저에게 전해지는가 ? -> 스케쥴링 로직은 안 전해짐 vs EtaNotice는 진짜 발송되는 공지용임

약속 내 참여한 모든 사용자에게 전해지는가? -> 이건 둘다 맞는 개념

2)번만으로 Notice에 대한 용어를 통일하고자 하면 제리가 제안한 구조로 해도 괜찮을 것 같고 만약 1번 까지 Notice의 개념 정의에 포함한다고 한다면 저는 Trigger로 Notice와 도메인을 구분하는 것도 좋을 것 같아요. 다만 리소스가 드는 일이니 Notice로 유지하는 방향이 나아보입니다!

coli-geonwoo · 2025-02-18T18:09:31Z

backend/src/main/java/com/ody/eta/service/EtaSchedulingService.java

-        //redis 실패시 재전송
+    public void sendNotice(long meetingId) {
+        meetingRepository.findById(meetingId)
+                .ifPresent(meeting -> {


오.. 약속 검증까지.. 역시 꼼꼼하네요 조조 👍

coli-geonwoo · 2025-02-18T18:13:01Z

backend/src/main/java/com/ody/notification/domain/message/DirectMessage.java

@@ -27,4 +31,19 @@ public static DirectMessage createMessageToSelf(Notification notification) {

        return new DirectMessage(message);
    }


[제안]

DirectMessage 클래스에서 createMessageToSelf는 더이상 쓰이는 곳이 없는 것 같아요!

coli-geonwoo · 2025-02-18T18:16:14Z

backend/src/main/java/com/ody/notification/domain/notice/Notice.java

+
+@Getter
+@RequiredArgsConstructor
+public abstract class Notice {


[사소한 제안]

이것도 Notice의 개념정의와 관련이 있다고 생각하는데, 만약 특정 약속 대상자 모두에게 뿌리는 공지를 Notice로 가정한다면 개념상 meetingId를 들고 있어도 괜찮다고 생각합니다.

coli-geonwoo · 2025-02-18T18:18:53Z

backend/src/main/java/com/ody/notification/service/NoticeService.java

+    private final FcmEventPublisher fcmEventPublisher;
+    private final TaskScheduler taskScheduler;
+
+    public <T extends AbstractMessage> void send(Notice notice, T t) {


제네릭을 통한 활용성 확장이 좋아요 👍

coli-geonwoo · 2025-02-18T18:35:34Z

backend/src/main/java/com/ody/eta/domain/EtaSchedulingKey.java

+        return new EtaSchedulingKey(
+                mate.getMember().getDeviceToken().getValue(),
+                mate.getMeeting().getId(),
+                LocalDateTime.of(mate.getMeeting().getDate(), mate.getMeeting().getTime())


[사소한 제안]

Meeting.getMeetingTime() 활용하시는 건 어떤가요?

coli-geonwoo · 2025-02-18T18:38:08Z

backend/src/main/java/com/ody/eta/domain/EtaSchedulingKey.java

+        );
+    }
+
+    public String serialize() {


[순수한 질문]

이건 정말 순수한 질문인데요. json 형태로 redis 에 저장하면 아마 Java 객체로 역직렬화 할 수 있을 것 같은데 delimiter를 이용해 String 값을 저장하고 파싱하도록 한 이유가 따로 있는지 궁금해요. 메모리 공간 때문인가요?

coli-geonwoo · 2025-02-18T18:40:10Z

backend/src/main/java/com/ody/eta/repository/EtaSchedulingRedisTemplate.java

+                .set(etaSchedulingKey.serialize(), LocalDateTime.now().toString(), ttlMs, TimeUnit.MILLISECONDS);
+    }
+
+    public String get(EtaSchedulingKey etaSchedulingKey) {


[제안]

어떤걸 가져오는지 잘 모르겠어요
getXXX로 의미를 부여해주면 더 잘 읽힐 것 같아요!

coli-geonwoo · 2025-02-18T18:42:34Z

backend/src/main/java/com/ody/eta/service/EtaSchedulingService.java

    }

-    public void sendNotice(long meetingId) {
-        meetingRepository.findById(meetingId)
+    private void noticeGroupMessageAndCache(EtaSchedulingNotice notice) {


[사소한 제안]

파라미터도 EtaSchedulignNotice를 받고 있어서 그룹 메시지를 보내는 것보다 etaschedulingnotice를 보낸다는 의미를 더 담으면 좋을 것 같아요

sendEtaSchedulingNoticeAndCache 어떠신가요?

coli-geonwoo · 2025-02-18T18:57:25Z

backend/src/test/java/com/ody/eta/service/EtaSchedulingServiceTest.java

+
+        @DisplayName("재발송 시나리오 : 스케줄링 그룹 알림 전송 -> ETA 요청 X -> 스케줄링 개인 알림 재전송")
+        @TestFactory
+        Stream<DynamicTest> resendCase() {


다이나믹 테스트 좋네요 👍 덕분에 흐름이 잘 이해되었습니다.

mzeong · 2025-02-20T15:00:32Z

backend/src/main/java/com/ody/meeting/service/MeetingService.java


    @Transactional
    public MeetingSaveResponseV1 saveV1(MeetingSaveRequestV1 meetingSaveRequestV1) {
        String inviteCode = generateUniqueInviteCode();
        Meeting meeting = meetingRepository.save(meetingSaveRequestV1.toMeeting(inviteCode));
        scheduleEtaNotice(meeting);
+        scheduleNoticeIfUpcomingMeeting(meeting); // TODO: 예외상황) 약속시간 30분 이내 약속 생성의 경우, 참가한 Mate가 없어 스케줄링 사이클이 걸리지 않음. 스케줄링 없이 바로 오디창이 시작되는 경우 안드에서 처리할지, Mate save 시점에 엣지 케이스 둘지 고민.


이 부분 안드에서 처리하는 걸로 결론난 건가요? 그렇다면 투두는 지워도 될 것 같아요

mzeong · 2025-02-20T15:02:58Z

backend/src/main/java/com/ody/meeting/service/MeetingService.java

+    }
+
+    private void scheduleNoticeIfUpcomingMeeting(Meeting meeting) {
+        LocalDateTime meetingDateTime = LocalDateTime.of(meeting.getDate(), meeting.getTime());


이곳에서도 getMeetingTime 사용해도 될 것 같아요~

mzeong · 2025-02-20T15:05:09Z

backend/src/main/java/com/ody/notification/domain/NotificationType.java

@@ -6,8 +6,7 @@ public enum NotificationType {
    DEPARTURE_REMINDER,
    NUDGE,
    LEAVE,
-    MEMBER_DELETION,
-    ETA_NOTICE,
+    MEMBER_DELETION


컴마는 남겨두어도 좋을 것 같아요 😙

Suggested change

MEMBER_DELETION

MEMBER_DELETION,

mzeong · 2025-02-20T15:16:11Z

backend/src/main/java/com/ody/notification/domain/message/GroupMessage.java

-                .putData("meetingTime", meeting.getMeetingTime().format(FORMATTER))
+                .putData("type", etaSchedulingNotice.getType().name())
+                .putData("meetingId", String.valueOf(etaSchedulingNotice.getMeetingId()))
+                .putData("meetingTime", etaSchedulingNotice.getMeetingTime().format(FORMATTER))
                .setTopic(fcmTopic.getValue())
                .build();

        return new GroupMessage(message);
    }


TTL이 만료되면 디바이스 토큰을 이용해 개인에게 Notice를 하기 때문에 2번으로 정의하는 것도 부정확하지 않나요? 저는 로그에서 확인할 수 있는가를 기준으로 Notification, Notice를 나눴다고 이해했는데 조조의 정의가 궁금하네요

mzeong · 2025-02-20T15:24:47Z

backend/src/test/java/com/ody/common/Fixture.java

+    public static Member Member(long memberId, DeviceToken deviceToken) {
+        return new Member(memberId, MEMBER1.getAuthProvider(), MEMBER1.getNickname(), "imageUrl1", deviceToken, MEMBER1.getRefreshToken(), null);
+    }
+
+    public static Mate Mate(long mateId, Meeting meeting, Member member) {
+        return new Mate(mateId, meeting, member, member.getNickname(), ORIGIN_LOCATION, 60L, null);
+    }
+


[질문] 정적 필드보다 메서드 형태가 좋은가요?

mzeong · 2025-02-20T15:26:52Z

backend/src/test/java/com/ody/eta/service/EtaServiceTest.java

    @DisplayName("ETA 목록 조회 시 API 호출 카운팅 Redisson 분산락 동시성 테스트")
    @Nested
-    public class RedissonDistributedLockTest {
+    class RedissonDistributedLockTest {


[질문] 해당 테스트 코드는 남겨지는 건가요 어떻게 되나요?

eun-byeol added 12 commits January 14, 2025 16:47

feat: 특정 날짜 내 약속 조회 쿼리 구현

fe65986

feat: 약속 시간 30분 전 ETA 스케줄링 알림 전송 구현

607965f

feat: ETA 스케줄링 알림 전송 시 약속 검증 추가

9eb79e7

feat: Notice 관련 도메인 분리

da0cd77

chore: Redis Lettuce 설정

1bb6e60

feat: ETA 스케줄링 알림 및 Redis Keyspace Notifications 구현

84e8ecc

feat: 당일 약속 ETA 스케줄링 알림 등록

e0f6a23

feat: ETA 시에 스케줄링 캐시 업데이트

108f9d5

test: 실패하는 테스트 코드 수정

9ce895e

test: fixture 추가 및 레디스 캐시 클리너 적용

410a3f2

test: 약속 시간별 스케줄링 테스트 케이스 추가

a73408b

refactor: 메서드 순서 변경

8c0523c

eun-byeol linked an issue Jan 29, 2025 that may be closed by this pull request

feature: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 #941

Open

eun-byeol changed the title ~~feature: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전~~ feature: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전(리뷰X) Jan 29, 2025

eun-byeol self-assigned this Jan 29, 2025

eun-byeol added BE FEATURE labels Jan 29, 2025

Merge branch 'develop' into feature/941

4e49f1a

eun-byeol added 8 commits January 30, 2025 15:41

test: RedisTestContainer Timeout 변경

8961515

feat: 공지 발송 시 약속 시간 검증 추가

cf06203

feat: 사용하지 않는 Redisson 제거

45a25c3

test: api call 동시성 테스트 disabled 처리

92fe74e

test: 테스트 클래스명 변경

57e565d

fix: TestContainer ListeningPort 설정 추가

7e08d8e

refactor: EtaSchedulingRedisTemplate 상속으로 변경

4bd47aa

test: cleaner 메서드명 통일

d3fe0d3

chore: ttl 만료 트리거 로그 수정

76b1d3a

eun-byeol requested a review from mzeong February 2, 2025 16:16

eun-byeol requested a review from coli-geonwoo February 2, 2025 16:16

eun-byeol changed the title ~~feature: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전(리뷰X)~~ feature: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 Feb 2, 2025

test: 특정 시간에 실패하는 테스트 수정

7d914f3

eun-byeol changed the title ~~feature: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전~~ feat: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 Feb 3, 2025

mzeong reviewed Feb 18, 2025

View reviewed changes

coli-geonwoo reviewed Feb 18, 2025

View reviewed changes

mzeong reviewed Feb 20, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 #963

feat: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 #963

eun-byeol commented Jan 29, 2025 •

edited

Loading

github-actions bot commented Jan 29, 2025 •

edited

Loading

github-actions bot commented Feb 2, 2025 •

edited

Loading

mzeong left a comment •

edited

Loading

mzeong Feb 18, 2025

coli-geonwoo Feb 18, 2025

mzeong Feb 20, 2025

mzeong Feb 18, 2025

mzeong Feb 18, 2025

mzeong Feb 18, 2025

coli-geonwoo left a comment

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

coli-geonwoo Feb 18, 2025

mzeong Feb 20, 2025

mzeong Feb 20, 2025

mzeong Feb 20, 2025

mzeong Feb 20, 2025

mzeong Feb 20, 2025

mzeong Feb 20, 2025

		@@ -27,4 +31,19 @@ public static DirectMessage createMessageToSelf(Notification notification) {

		return new DirectMessage(message);
		}

feat: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 #963

Are you sure you want to change the base?

feat: 약속 30분 전 최초 스케줄링 책임 백엔드로 이전 #963

Conversation

eun-byeol commented Jan 29, 2025 • edited Loading

🚩 연관 이슈

📝 작업 내용

1. 스케줄링 알림 발송 & fallback 전략

2. 스케줄링 등록 예외 처리

3. [리팩터링] Notice 관련 로직 분리

4. [리팩터링] GroupMessage, DirectMessage 추상화

🏞️ 스크린샷 (선택)

🗣️ 리뷰 요구사항 (선택)

github-actions bot commented Jan 29, 2025 • edited Loading

Test Results

github-actions bot commented Feb 2, 2025 • edited Loading

📝 Test Coverage Report

mzeong left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coli-geonwoo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eun-byeol commented Jan 29, 2025 •

edited

Loading

github-actions bot commented Jan 29, 2025 •

edited

Loading

github-actions bot commented Feb 2, 2025 •

edited

Loading

mzeong left a comment •

edited

Loading