fix(alerting/I-1): retry endpoint resets attempts to 0 instead of incrementing

AlertNotificationRepository gains resetForRetry(UUID, Instant) which sets
attempts=0, status=PENDING, next_attempt_at=now, and clears claim/response
fields. AlertNotificationController calls resetForRetry instead of
scheduleRetry so a manual retry always starts from a clean slate.

AlertNotificationControllerIT adds retryResetsAttemptsToZero to verify
attempts==0 and status==PENDING after three prior markFailed calls.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
hsiegeln
2026-04-20 08:25:59 +02:00
parent d74079da63
commit 424894a3e2
4 changed files with 47 additions and 4 deletions

View File

@@ -69,10 +69,7 @@ public class AlertNotificationController {
}
// Reset for retry: status -> PENDING, attempts -> 0, next_attempt_at -> now
// We use scheduleRetry to reset attempt timing; then we need to reset attempts count.
// The repository has scheduleRetry which sets next_attempt_at and records last status.
// We use a dedicated pattern: mark as pending by scheduling immediately.
notificationRepo.scheduleRetry(id, Instant.now(), 0, null);
notificationRepo.resetForRetry(id, Instant.now());
return AlertNotificationDto.from(notificationRepo.findById(id)
.orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND)));

View File

@@ -118,6 +118,21 @@ public class PostgresAlertNotificationRepository implements AlertNotificationRep
""", Timestamp.from(nextAttemptAt), status, snippet, id);
}
@Override
public void resetForRetry(UUID id, Instant nextAttemptAt) {
jdbc.update("""
UPDATE alert_notifications
SET attempts = 0,
status = 'PENDING'::notification_status_enum,
next_attempt_at = ?,
claimed_by = NULL,
claimed_until = NULL,
last_response_status = NULL,
last_response_snippet = NULL
WHERE id = ?
""", Timestamp.from(nextAttemptAt), id);
}
@Override
public void markFailed(UUID id, int status, String snippet) {
jdbc.update("""