[carpawell]

If anything blocks epoch tick, do not simply try it once and wait for the next chain "NewEpoch" notification, instead, try to predict the next tick time and never stop trying. An epoch stuck is a critical error in the system, IRs must try their best.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 32.83%. Comparing base (b9c6b05) to head (b3ceaa5).

Files with missing lines	Patch %	Lines
pkg/innerring/innerring.go	0.00%	9 Missing ⚠️
pkg/timers/timer.go	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4274      +/-   ##
==========================================
- Coverage   32.83%   32.83%   -0.01%     
==========================================
  Files         673      673              
  Lines       41706    41713       +7     
==========================================
+ Hits        13694    13696       +2     
- Misses      28012    28017       +5     

☔ View full report in Codecov by Harness.
📢 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.

[roman-khimov]

Why not resetting in error handler? This seems dangerous by default (some other timers can have problems with this).

[Copilot]

🟡 Changes recommended

The timer can submit the epoch transaction on every block when no valid duration is available, so the active moderate-severity issue must be fixed.

1 open issue

• Zero epoch duration causes repeated epoch transaction submissions · New

What changed in this PR

Updates epoch timers to keep retrying epoch ticks using the configured epoch duration when NewEpoch notifications are delayed or unavailable.

Changes:

• Replaces one-shot completion state with persistent epoch-duration scheduling.
• Reschedules the next epoch tick after each attempted handler execution.
• Stores the epoch duration during timer resets.
• A moderate issue remains when epochDur is zero: handlers may be invoked once per block instead of preserving one-shot behavior until a valid duration is available.

File	Description
pkg/​timers/​timer.go	Implements recurring epoch-tick scheduling and reset duration tracking.

_{Review effort: Lite}

[carpawell]

it does not differ much from the previous behaviour: Reset is called from the beginning of IR's journey

[carpawell]

fixed with providing initial epoch duration for IR app

[End-rey]

This looks like the timer commit from #4272, with both issues I pointed out there fixed.

[carpawell]

Why not resetting in error handler?

What is "error handler"? Current IR does not wait for new epoch tx inclusion, it just sends notary request, do you want it to wait for NewEpoch notification (or vub expiration)?

This seems dangerous by default (some other timers can have problems with this).

There are no other timers, only the new epoch will have this exclusive opportunity. If everything is ok, it will be reset likely almost immediately by the NewEpoch event. But if smth is wrong, the next tick will, at least, happen.

@roman-khimov

[carpawell]

@roman-khimov, treat this PR like time.Timer -> time.Ticker evolution. Reset will always be called after a real NewEpoch event is handled. What exactly bothers you?