fix(api): add default sort order for action job queries#37667
Closed
mtschoen wants to merge 3 commits into
Closed
Conversation
FindRunJobOptions does not implement ToOrders(), so action job API endpoints return results in ascending primary-key order (oldest first). Paginated queries like ?status=success&limit=20 return the 20 oldest jobs rather than the 20 most recent. The sibling FindRunOptions already has ToOrders() returning DESC (added in go-gitea#28084 to preserve the pre-refactor .Desc("id") call), but FindRunJobOptions never had ordering — the original hand-written FindRunJobs() also lacked it. Add ToOrders() returning `action_run_job.id DESC` and a compile-time interface assertion, following the pattern from go-gitea#33569 (artifact ordering fix). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
GiteaBot
added
the
lgtm/need 2
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Internal callers (webhook dispatch, concurrency checks) pass FindRunJobOptions with zero-value ListOptions, so they should not get DESC ordering imposed — it changed the webhook payload order and broke Test_WebhookWorkflowJob which expects jobs in creation order. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Closing in favor of a better approach: adding explicit — Matt (with help from Claude Code) |
4 tasks
silverwind
added a commit
that referenced
this pull request
May 13, 2026
…37672) Adds `sort` and `order` query parameters to all action job list API endpoints (`/admin/actions/jobs`, `/repos/{owner}/{repo}/actions/jobs`, `/repos/{owner}/{repo}/actions/runs/{run}/jobs`, `/user/actions/jobs`), following the existing `OrderByMap` pattern used by repo/user search endpoints. - Default is `id` / `asc` (backwards compatible — matches previous DB natural order) - Only `id` sort field for now; the map is extensible for future fields - Returns 422 for invalid sort/order values - `ToOrders()` returns empty string when `OrderBy` is unset, so internal callers (webhook dispatch, concurrency checks) are unaffected Closes: #37666 Supersedes: #37667 Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: silverwind <me@silverwind.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FindRunJobOptionsdoes not implementToOrders(), so action job API endpoints return results in ascending primary-key order (oldest first). Paginated queries like?status=success&limit=20return the 20 oldest jobs rather than the 20 most recent.Add
ToOrders()returning`action_run_job`.`id` DESCand a compile-time interface assertion, matching the existingFindRunOptions.ToOrders()from #28084 and the artifact ordering fix pattern from #33569.Fixes #37666
Built with Claude Code.