Closed issues should sort by close date, not creation date

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 2mo ago ·closed by Colby Knox

The closed-issues list sorts by creation date, so a long-running issue that was just resolved sinks to the bottom while a stale issue opened yesterday and closed immediately sits at the top. When you are looking at closed issues you almost always want "what got finished recently", and that is the one ordering the list cannot give you.

Current behaviour, server.js around the issues-tab query:

SELECT * FROM discussions
 WHERE page_id = ? AND status = ? AND deleted_at IS NULL
 ORDER BY is_pinned DESC, created_at DESC

The same ORDER BY serves both tabs. For open issues, created_at DESC is right. For closed issues it answers the wrong question.

Ask

When the closed tab is showing, order by closed_at DESC.

The column already exists and is already populated: the triage route sets closed_at, closed_by_id and closed_by_name on close, and nulls all three on reopen. So this is an ordering change, not a schema change.

Details worth getting right

Reopen then re-close must move it back to the top. Since reopening nulls closed_at and re-closing sets it fresh, ordering by closed_at gets this for free, whereas ordering by updated_at would also be moved by an unrelated edit or a new comment.
Rows closed before closed_at existed will be NULL. They should sort last rather than first; SQLite sorts NULL lowest, so ORDER BY closed_at DESC already puts them at the bottom, but it is worth confirming against real data rather than assuming, and worth deciding whether they should instead fall back to created_at.
Pinning still wins. Keep is_pinned DESC as the first key.
The same reasoning applies to pull requests if their list has the same shape, and probably to the per-user "My issues" view.

Not just the wiki page

adom-wiki issue list --status closed should agree with whatever the page does, or the CLI and the web UI will disagree about what "most recent" means.

1 Reply

Colby Knox · 2mo ago

Shipped and live. Closed lists now lead with the most recently closed, on both the Issues tab and the discussions API, so adom-wiki issue list --status closed and the page cannot disagree about what "most recent" means.

Live proof from this page, which happens to contain the exact motivating case:

closed=2026-07-30T17:34  created=2026-07-30  Add UI for page visibility
closed=2026-07-30T17:11  created=2026-07-30  Follow-up to #94
closed=2026-07-30T16:57  created=2026-07-22  Interactive 3D viewer, downstream consumer needs

That third one was opened on the 22nd and closed today. Under creation order it sat below everything filed this morning, which is precisely the issue you would most want to see when opening the closed tab.

closed_at rather than updated_at, deliberately. It is cleared on reopen and set fresh on re-close, so a reopened-then-closed issue returns to the top, while an unrelated edit or a new comment does not move it. updated_at would have been wrong in both directions.

Rows predating the column are NULL. SQLite sorts NULL lowest, so they sink rather than claiming the top, and created_at is the secondary key so they stay in a sensible order among themselves. Verified against real data rather than assumed: 89 closed issues on this page, and the pre-column ones land at the bottom.

Pinning still wins, as before.

Tests cover the inverted case (old issue closed today outranking a new issue closed a year ago), NULL placement, reopen-then-reclose returning to the top, and that the rendered HTML agrees with the API.

Pull requests were mentioned in the filing as possibly having the same shape. Their list does not use this query, so it is untouched here; if the PR tab shows the same problem it is worth its own issue.