Events of the recent-activity feed that share one timestamp now list by
kind (grant, invoice, payment, tier change, as before) and, within a kind,
the one the console recorded later first. Invoice and payment events had no
Seq, so two of them at one instant fell through to their summary text and
organization id: "$100.00" listed above "$20.00" and Zeta above Alpha
whichever was recorded later. They now carry their own row's id, as grant
and tier events already did, and activityLess breaks the tie on it, so
every event has one place in the order. The comment on ActivityEvent.Seq
and on activityLess say so. The requirement "Invoice and payment events
are placed when they happened" now states the order of events that share
one timestamp, through the change same-instant-feed-order, archived in
this commit with the delta synced into the main spec.
How it was shown to change only that: TestRecentActivityTiesListTheLaterWrittenFirst
(invoices of two organizations, invoices of one organization, rows of one
kind in any input order) fails in all three subtests at the parent and
passes here. The feed's golden diff is exactly two pairs of rows swapped in
feed.json and in feed.html: Alpha's invoice above Zeta's, and "$20.00"
above "$100.00" for the invoices of one organization. Names and results of
internal/server are equal to the parent's (1473 at the parent, 1477 here:
the new test and its three subtests), 0 failures. Four breaks (the invoice
Seq, the payment Seq, the id direction, the kind direction) are each caught
by the new test or the feed's golden. The lint snapshot is unchanged
(0 added, 0 removed). Walkthroughs are equal at the parent and here (16
pass, 6 skip); screens at the parent and here differ from the baseline only
in the masked regions, so operator-overview is unchanged: the demo feed
holds no same-kind ties.
Unprobed: payments tied in the database. The database subtests tie
invoices only; ties of payments, and of three rows of one kind, are checked
without a database through the comparator, because the tie rests on the
payment row carrying its id, which the comparator check and the payment
break cover.