recurring(): schedule profile re-evaluation, and floor epoch days (LYT-391)

[junichi-cstk]

Two fixes to recurring(), both found while auditing the lio side of LYT-391.

1. Anniversary audiences were never scheduled for re-evaluation

findDateMathFn produced a boundary fn only for a now±N string literal inside a binary or BETWEEN node. recurring() is now-relative without containing any such literal, so it yielded no boundary fns at all — DateConverter reported HasDateMath=false, callers never flagged the segment as needing recalculation, and nothing scheduled the profile to be re-evaluated on its anniversary.

The practical effect: an anniversary audience only picked up a profile when some unrelated event happened to re-evaluate it. A dormant profile never entered on its birthday, and — worse for a "send on birthday" trigger — never exited the day after. That is precisely the failure mode the original feature request (lytics/lio#34919) was filed to escape:

Since profile evaluation only happens when there are events or scoring type processes, a subset of profiles would be inadvertently excluded from the audience.

RecurringBoundary returns the next UTC midnight at which the expression changes value:

State	Boundary
Currently false	start of the next recurrence day
Matching today	start of tomorrow (the exit edge)
Never changes again (n=1 past its anchor)	zero — not scheduled

It mirrors the evaluators rather than idealizing them: anchors with no counterpart in a period are skipped, not clamped — Feb 29 recurs only in leap years, the 31st only in months that have one. Shapes the evaluators reject (unknown period, non-positive or fractional n, non-literal period or offset) return no boundary fn, so an invalid recurring() isn't flagged for recalculation either.

2. Pre-1970 anchors recurred a day late

The every-n-days path divided epoch seconds with / on both sides — Go in the boundary calculation, Java in the generated Painless. Both round toward zero, so an anchor before 1970 whose time-of-day wasn't midnight bucketed one day too high. Pre-1970 birth dates are the headline input for recurring(), so this is the common case, not an edge.

- long d = params.todayDay - (doc['f'].value.toInstant().getEpochSecond() / 86400) - params.offset;
+ long d = params.todayDay - Math.floorDiv(doc['f'].value.toInstant().getEpochSecond(), 86400L) - params.offset;

Both sides move together — flooring one alone would make an Elasticsearch scan and in-process evaluation disagree for exactly these profiles. Post-1970 values are unaffected (truncation and flooring agree for non-negative seconds), so no audience of recent dates changes behavior.

Verification

Full suite green: 19 packages, 0 failures.

Beyond exact-value cases per period, TestRecurringBoundaryIsExactFlipPoint walks 550 days of "now" per configuration and asserts the returned boundary is the precise instant the predicate flips — checked against an independent copy of the predicate rather than against the implementation. That oracle caught a wrong expectation of mine while writing these tests.

Downstream

lio's RecurringMatch needs the matching floor change, landing with its go.mod bump — the two must ship together. No other lio change is required: with this branch, a work segment containing recurring() reaches full parity with existing datemath (DateMathCalc → ScheduleExitTrigger → segDateCalcs → CalculateRecalcTime → reevalqueue), verified end-to-end against a local replace.

🤖 Generated with Claude Code