fix(payment): prevent Int64 overflow panic in settle-timestamp arithmetic

[puneet2019]

Linear

https://linear.app/mocanetwork/issue/MOCA-385/prevent-int64-overflow-panic-in-stream-record-updates

What

UpdateStreamRecord and TryResumeStreamRecord called Int.Int64() on an unbounded sdkmath.Int to compute the settle timestamp. When a stream account's pay-duration exceeded MaxInt64 seconds (~2.9e11 years), the SDK panicked with "Int64() out of bound". Both functions run inside the storage EndBlocker with no recover(), so the panic was deterministic across every validator and halted the chain.

Why it happens

The settle-timestamp formula is:

settleTimestamp = currentTimestamp - forcedSettleTime + (staticBalance + bufferBalance) / |netflowRate|

payDuration blows past MaxInt64 when |netflowRate| is tiny relative to the balance — reachable when SP prices are low (governance/devnet) and the account is heavily funded, or when a rate decrease (object deletion / discontinue) shrinks the denominator. The storage EndBlocker (ForceDeleteObject → UnChargeObjectStoreFee → UpdateStreamRecord) then panics, and every validator hits a CONSENSUS FAILURE at the same height.

Fix

Compute the full expression in arbitrary-precision sdkmath.Int, then handle an out-of-range result by intent, not by call site:

• User-initiated deposit (positive static-balance change, no rate change) that would overflow → reject with ErrSettleTimestampOverflow. The depositor is over-funding past what we can represent and can simply deposit less. This is the only path where the degenerate state is genuinely user-created.
• Every other path → saturate the settle timestamp to MaxInt64:
  • forced EndBlocker updates (an error there would re-trigger the same halt via abci.go panic("should not happen"));
  • rate decreases from object deletion / discontinue;
  • lazy re-pricing when the SP price falls.

The settle timestamp is only a scheduling hint for the auto-settle queue — recomputed on the next balance change or bucket touch — so capping it is loss-free and never blocks a legitimate object deletion. This avoids the asymmetry of rejecting a user's own MsgDeleteObject.

Why not cap/refund the deposit?

Storage prices are SP-set (median-aggregated, time-versioned, recomputed monthly), and buckets are re-priced on every touch. Prepayment does not lock a price — staticBalance drains at the current rate and is withdrawable anytime. So "N years of runway" isn't a stable quantity, and a time-based deposit cap would fight the floating-price model while only ever triggering at the absurd ~2.9e11-year boundary. The overflow is a representation limit, so it gets a representation fix.

ErrSettleTimestampOverflow (code 1214) is added to x/payment/types/errors.go.

Tests

In the existing x/payment/keeper/stream_record_test.go (no new files):

Test	Scenario	Asserts
..._ForcedSaturates	forced rate-decrease (EndBlocker discontinue — the halt repro)	no panic, no error, settle = MaxInt64
..._UserDepositRejected	non-forced deposit (positive static-balance change)	returns ErrSettleTimestampOverflow
..._RateDecreaseSaturates	non-forced rate-decrease (user MsgDeleteObject / re-price)	no error, settle = MaxInt64 (delete never blocked)
TestTryResumeStreamRecord_SettleTimestampInt64Overflow	deposit to frozen account	returns ErrSettleTimestampOverflow
..._SilentWrap	forced, secondary full-expression overflow	settle = MaxInt64, not negative

Checklist

• Tests included
• Changelog updated
• CI green
• 2 approvals