Order transactions by date

[leofelix077]

Quick fix PR to get all fetched transactions and order them by their created at date, instead of depending on the returned groupings of the backend, which can group failed together, and successful together, and order them by date internally, instead of ordering the entire result/outcome by date

[github-actions]

PR Preview build is ready: https://github.com/stellar/freighter/releases/tag/untagged-72b7ef5553367b73d788 (SDF collaborators only — install instructions in the release description)

[Copilot]

Pull request overview

This PR ensures account history is displayed in true reverse-chronological order by sorting all fetched operations by created_at on the client, rather than relying on backend grouping (e.g., failed vs successful) that can break global ordering.

Changes:

• Sort fetched account history operations by created_at descending before storing in state/cache.
• Add an e2e regression test that interleaves failed and successful transactions out of order and asserts the UI re-sorts correctly (including within the asset detail view).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
extension/src/helpers/hooks/useGetHistory.tsx	Sorts fetched (or cached) history operations by created_at desc before dispatching/saving.
extension/e2e-tests/accountHistory.test.ts	Adds an e2e test to verify failed + successful transactions are ordered together by date, and updates stubs import.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[piyalbasu]

Three observations before merge — none blocking, the fix is fine to ship.

1. The sort is load-bearing for the section reducer in useGetHistoryData.tsx. That reducer creates a new monthYear bucket each time the month changes between adjacent items, so it requires sorted input — without this sort, history would render with duplicate non-contiguous month headers (e.g., two separate 'March 2025' sections). Worth a one-line comment on the sort here noting that downstream grouping depends on it, otherwise a future refactor that drops the sort produces a silent visual bug with no type/test failure.

2. Worth a follow-up at the backend. With Mercury disabled in prod, freighter-backend/src/helper/horizon-rpc.ts fetchAccountHistory is the only path serving real users — a thin passthrough of one Horizon call (order("desc").includeFailed(true)). If Horizon really is returning grouped data, a one-line sort there gives every consumer (extension, mobile, any future v2 reimplementation) the invariant without each client re-implementing it. The client sort here is still useful as defense-in-depth (and the section reducer needs it locally), but the canonical fix probably belongs upstream.

3. Inline notes on the rationale comment and the sort itself below.

[piyalbasu]

This comment plants a server-side cause that hasn't been reproduced against the actual prod path. With Mercury disabled in prod, /account-history is a thin Horizon passthrough (order("desc").includeFailed(true)) — Horizon orders operations by id desc, which is chronological including failed. So either Horizon itself is returning grouped data (a quirk of includeFailed+join("transactions") worth verifying with a real curl), or the reshuffle is happening somewhere we haven't found yet.

Two options:

• Soften to a defensive rationale that doesn't make an unverified claim: // Defensive: guarantee desc order regardless of upstream behavior. The section reducer in useGetHistoryData.tsx requires sorted input.
• Or do a 10-minute repro against a reproducing account and document what you actually saw — that's load-bearing context for whoever picks this up next.

As written, a future maintainer reads this, assumes the backend is at fault, and never investigates further — while freighter-mobile (or any future client) still sees the bug.

[piyalbasu]

@leofelix077 Wanted to follow up on the above Claude-generated comment:

Looks like you have a test account that you were able to replicate this. Would you mind quickly using Claude to check if the reason this is coming back in the wrong order is because of something freighter-backend is doing or because stellar-sdk/Horizon is returning these in the wrong order. Ideally, the BE would return things in the right order. Maybe there's some learnings that we can apply to the freighter-backend-v2 version of this.

Either way, I think it's fine to apply this client-side fix for now

[leofelix077]

This is actually coming from the e2e test, not my own account to reproduce it

Checking against the backend it confirms your suspicions regarding Mercury, so I updated the comment not to mention backend but just force the sorting, as suggsted above

[piyalbasu]

Two small things on the sort itself:

Schwartzian is overkill here. N is capped at TRANSACTIONS_LIMIT=100 and Date.parse on ISO strings is ~microseconds — the decorate-sort-undecorate idiom isn't paying for itself, and readers have to mentally unwind it to confirm what it does. The plain form is shorter and equivalent in practical cost:

const data = [...fetched].sort(
  (a, b) => Date.parse(b.created_at) - Date.parse(a.created_at),
);

Date.parse(undefined) returns NaN, and a NaN-returning comparator yields implementation-defined non-stable order. Types say created_at is required string, so this is defensive — but a single malformed/missing record silently corrupts the entire sort. Cheapest guard inline: Date.parse(x.created_at) || 0 (or || -Infinity to bucket bad records at the bottom).