fix(rules): sort lock states most-urgent-first on the Locks tab for #708

[hdimer]

Fixes #708.

What's wrong

On the Rule page's Locks tab, the State column renders least-urgent-first: OK and UNKNOWN on top, STUCK at the bottom, which is the opposite of what lockStateComparator's own doc comment promises (ERROR > STUCK > REPLICATING > OK > UNKNOWN). That matches the screenshot on the issue, where the descending arrow is showing but every visible row is OK.

lockStateComparator returns priorityB - priorityA, i.e. it already ranks the most urgent state first. AG-Grid treats a colDef.comparator as defining ascending order and negates its result when 'desc' is requested (SortService.compareRowNodes). DetailsRuleLocksTable.onGridReady asked for sort: 'desc', so the comparator got inverted a second time.

That also explains the issue's literal wording ("the sorting does not take effect" rather than "the sorting is backwards"). AG-Grid's default sort cycle is asc → desc → none, so starting the column at 'desc' meant the user's first header click landed on none: the sort disappeared and rows fell back to stream-arrival order, so clicking looked like a no-op.

The fix

One word: ask for 'asc' so the comparator is used as written. Default order becomes STUCK → REPLICATING → OK → UNKNOWN, and clicking the header now toggles to the reverse instead of clearing the sort.

I considered the other direction, flipping lockStateComparator to priorityA - priorityB and keeping 'desc', which is the more conventional AG-Grid shape. I didn't go that way because src/lib/core/utils/rule-sorting-utils.test.ts explicitly pins the current "most urgent first" contract ([...states].sort(lockStateComparator) must yield STUCK first), and ruleStateComparator/ruleActivityComparator in the same module follow the same convention, so flipping it is a three-comparator refactor plus a test rewrite off the back of a one-line UI bug. Happy to do it that way instead if you'd prefer the comparators to follow AG-Grid's convention.

Test

test/component/DetailsRuleLocks.test.tsx mounts the real DetailsRuleLocks, captures the grid API that the production onGridReady hands out (so the sort direction under test comes from the component, not from the test), feeds four rows in an order that is neither the expected result nor its reverse, and asserts the rendered order. It fails on main with [UNKNOWN, OK, REPLICATING, STUCK].

npm test is green (108 suites, 456 tests). tsc --noEmit clean, eslint reports no new problems on the touched file. I left the pre-existing Prettier violation in DetailsRuleLocks.tsx alone (an unrelated long template literal) rather than mixing reformatting into the fix.

One thing worth flagging, not fixed here

The same double inversion exists in two more places, both with a comment saying they prioritise error/stuck rules while doing the opposite:

• src/component-library/pages/Rule/list/ListRuleTable.tsx:162
• src/component-library/pages/DID/details/views/DetailsDIDRules.tsx:143

Both apply sort: 'desc' over ruleStateComparator, which is also written most-urgent-first. #708 only mentions the Locks tab so I kept the diff to that, but say the word and I'll fix those here or in a follow-up.

---

I used an AI assistant while investigating and writing this. The diagnosis, the fix, and the test were reviewed and verified by me against the real test suite.

---

Used AI assistance on this; I reviewed and tested the change myself.