Fixing flaky tests

[dorner]

I set Claude loose on three flaky tests I observed in CI. Hoping this squashes them!

Summary

Three independent flaky-test fixes, each with a different root cause but the same symptom: passes locally, fails intermittently on CI.

1. Inventory event replay tiebreaker (app/models/event.rb)

Event.for_organization ordered by (event_time, updated_at). When tests use travel_to to freeze the clock, multiple events get identical event_time, created_at, and updated_at. Postgres tiebreaks at its discretion — sometimes a DistributionEvent sorts before the AuditEvent it depends on, so InventoryAggregate.inventory_for replays them in the wrong order and validate_inventory fails with Could not reduce quantity by N - current quantity is 0.

Changed the secondary sort from :updated_at to :id. Insertion order is the only stable, never-changing tiebreak; id is unique and monotonic. Snapshot-correctness logic in most_recent_snapshot still uses updated_at (for detecting retroactive edits) and is unchanged.

Symptomatic example: spec/system/request_system_spec.rb:223 ("should change request to fulfilled").

2. Date Range Picker keyboard submit (spec/support/date_range_picker_shared_example.rb)

The shared example did:

fill_in "filters_date_range", with: date_range
find(:id, 'filters_date_range').native.send_keys(:enter)

fill_in types character-by-character, and each keystroke fires Litepicker.js handlers that can re-render the input. The .native reference grabs a Ferrum node id at one point in time; by the time send_keys(:enter) runs, the underlying DOM node has been replaced and Cuprite raises ObsoleteNode / No node with given id found.

Replaced the three uses with click_on "Filter", which re-resolves the Filter button at click time. All six consumers of the shared example (Donation, Transfer, Purchase, Distribution, Request, Adjustment) have a Filter button via the filter_button UI helper.

3. Partner CSV export spec — duplicate profiles (spec/services/exports/export_partners_csv_service_spec.rb)

The "should handle a partner with missing profile info" test did:

partners.first.update(profile: create(:partner_profile, no_social_media_presence: nil, ...))

The partner_profile factory defaults partner { Partner.first || create(:partner) }, so the new profile silently attached to the same partner that already had one — leaving two partner_profiles rows with the same partner_id. There is no DB-level unique constraint on that column, so Rails' has_one :profile lookup (WHERE partner_id = X LIMIT 1, no ORDER BY) returns whichever row Postgres picks. About half the time on CI, Rails saw the new profile as already-attached, no-op'd the assignment, and left the old populated profile in place — so the export contained the old profile's data instead of the empty one the test expected.

Destroyed the existing profile first and passed the partner explicitly to the new one, so there's only ever one row per partner.

Note: not bundled in this PR, but worth considering as a follow-up — adding a unique index on partner_profiles.partner_id would enforce the has_one invariant at the DB level and prevent this whole class of bug.

Test plan

• CI passes
• spec/system/request_system_spec.rb:223 runs green repeatedly (5/5 locally)
• All Date Range Picker shared examples pass across all 6 consumers (36/36 locally)
• spec/services/exports/export_partners_csv_service_spec.rb passes (11/11 locally)

[awwaiid]

All good!