feat: allow to reset migration max counter

[gfyrag]

Some migrations are, sometimes, not able to recover after a restart.
The new notification payload allow to reset the counter.

[coderabbitai]

Walkthrough

The migrations listener now handles a new "reset" notification prefix. Upon receiving this notification, the max_counter for the next version (lastVersion+1) is reset to 0 in the versions table. Errors from the update are logged but do not halt execution. This reset handling occurs before existing initialization logic.

Changes

Cohort / File(s)	Summary
Reset notification handler migrations/migrator.go	Added handling for "reset" notification prefix in the migrations listener. When received, resets max_counter to 0 for the next version (lastVersion+1) via an update on the versions table. Errors are logged and execution continues.

Sequence Diagram

sequenceDiagram
    participant L as Listener
    participant DB as Versions Table
    participant Log as Logger
    
    L->>L: Receive notification
    alt notification prefix is "reset"
        L->>DB: UPDATE versions SET max_counter=0<br/>WHERE version_id=lastVersion+1
        alt update succeeds
            L->>Log: Log success
        else update fails
            L->>Log: Log error
            L->>L: Continue (return nil)
        end
    else notification prefix is "init"
        L->>L: Handle init...
    else other
        L->>L: Continue
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Verify the SQL UPDATE query correctly targets the next version (lastVersion+1)
• Confirm max_counter reset to 0 is the intended behavior and value
• Review error handling appropriateness—logging without interruption is intentional
• Check that the reset path placement before "init: " handling reflects desired precedence

Poem

🐰 A counter resets to zero's call,
For versions waiting, one and all,
The listener hops through code so bright,
Reset comes first, then init's light! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding functionality to reset the migration max counter, which is directly supported by the code changes.
Description check	✅ Passed	The description explains the motivation (migrations unable to recover after restart) and the solution (new notification payload to reset counter), which aligns with the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/migrations-counter-reset

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

migrations/migrator.go (1)

348-357: Consider aligning the notification format with existing patterns.

The "reset" prefix doesn't include a colon, while "init: " and "continue: " do. This inconsistency means "reset" will match "reset", "reset:", or "reset: anything". If the reset notification should never carry additional data, this is fine. However, for consistency and to make the intent explicit, consider using "reset:" or a more restrictive pattern.

-case strings.HasPrefix(notification.Payload, "reset"):
+case notification.Payload == "reset":
     _, err = conn.Exec(ctx, `
         update `+m.getVersionsTable()+`
         set max_counter = 0
         where version_id = $1
     `, lastVersion+1)
     if err != nil {
         logging.FromContext(ctx).Debugf("failed to reset max counter: %v", err)
         return nil
     }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ea66e37 and e74070c.

📒 Files selected for processing (1)

• migrations/migrator.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

migrations/migrator.go (2)

logging/context.go (1)

• FromContext (12-20)

logging/logging.go (1)

• Debugf (21-23)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Ci

🔇 Additional comments (1)

migrations/migrator.go (1)

348-357: Reset logic is correct for the stated purpose.

The implementation correctly resets max_counter to 0 for the next migration version (lastVersion+1). The error handling is consistent with the existing "init: " case—logging at Debug level and continuing listener operation. This aligns with the PR objective of allowing recovery after restart when migrations cannot recover automatically.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.69%. Comparing base (ea66e37) to head (e74070c).

Files with missing lines	Patch %	Lines
migrations/migrator.go	0.00%	9 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #535   +/-   ##
=======================================
  Coverage   28.68%   28.69%           
=======================================
  Files         162      162           
  Lines        6644     6653    +9     
=======================================
+ Hits         1906     1909    +3     
- Misses       4622     4628    +6     
  Partials      116      116           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.