Repository navigation
fix(flags): stop month lookbacks overflowing into the next month - #5626
Conversation
setUTCMonth rolls an impossible date forward, so 1m on March 31 resolved to March 3. Subtract one unit at a time and clamp the day after every step, as the SDK spec requires.
The table tests call the parser directly. This one goes through matchFeatureFlagProperty on the last day of March.
marandaneto
left a comment
There was a problem hiding this comment.
The code looks good; no qualifying findings. Verdict: correct.
SDK performance: posthog-node1 change worth reviewing: 1 observed regression. Flags require at least a 5% change in the median and all six pairs agreeing on direction. This is a noise filter, not proof of a performance change or a CI gate.
View all results
Values are medians of paired measurements. Not flagged does not mean unchanged. Unavailable means a measurement could not be provided, not zero. Estimated allocation measurements retain their instrumentation uncertainty. RSS measures the whole process, not just SDK allocations; observed peaks are sampled checkpoints. Paired ranges in the diagnostics describe variability, not confidence intervals. Each shard uses its own runner; compare Before PR against With PR within a row, not across shards. Compared 102 metric rows; 102 rows shown in all results. Omitted or shortened data remain in |
Problem
relativeDateParseForFeatureFlagMatchingsubtracts months withsetUTCMonth, which rolls an impossible date forward. A1mfilter evaluated on March 31 resolves to March 3 instead of February 28, and1yon February 29 resolves to March 1. posthog-node and the Convex component use this parser for local evaluation, sois_date_beforeandis_date_aftercan answer differently from the flags service on those days.Changes
Months and years now subtract one unit at a time and clamp the day after every step, as the local evaluator spec requires, so a two-month lookback from March 31 gives January 28. The SDK still works in UTC where the spec asks for the team's timezone, and I left that alone.
Eight of the twelve new table cases fail on
main, and so does a new test that goes throughmatchFeatureFlagPropertywithis_date_after. I also compared the two helpers against a naive month-by-month loop for every day from 2019 through 2028, with lookbacks from 0 to 129 plus 4000 and 9999, and got no differences in 964,392 comparisons.I ran this in
node:24-slim:vitestinpackages/core(2368 passed, 2 skipped) andpackages/node(1516 passed), the flag specs inpackages/convex(83 passed),oxfmt --checkon the changed files, andoxlintonpackages/core/src.turbo run build --filter=posthog-nodealso passes.Release info Sub-libraries affected
Libraries affected
Checklist
If releasing new changes
pnpm changeset)🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Luan Taraschi directed this and Claude Code (Claude Opus 5.5) wrote it and ran the checks. It came out of the same spec comparison as PostHog/posthog-python#1212, which fixes the single-jump version of this bug in the Python SDK.