[codex] Fix duplicate schedule notifications

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.

[jjoonleo]

Summary

• Reject duplicate scheduleId values on schedule creation to prevent repeated notification inserts for the same schedule.
• Add a Flyway migration that deduplicates existing notification_schedule rows and enforces one notification row per schedule with a unique index.
• Make schedule notification refresh/delete paths tolerate pre-existing duplicate notification rows while cleaning them up.

Root Cause

The backend accepted repeated POST /schedules requests with the same client-generated scheduleId. The schedule row could remain singular while each request inserted another notification_schedule row. Later code expected exactly one notification row per schedule, causing failures such as IncorrectResultSizeDataAccessException or schedule refresh errors.

Validation

• ./gradlew test --tests devkor.ontime_back.service.ScheduleServiceTest --tests devkor.ontime_back.service.ScheduleServiceNotificationRefreshTest --tests devkor.ontime_back.service.PreparationUserServiceTest
• ./gradlew test

Production duplicate rows for the observed schedule were also manually reduced to one before this PR.