fix(listings): preserve explicit sort order

[iamomm-hack]

What does this PR do?

Preserves the user's selected listing sort instead of unconditionally moving featured, ongoing listings to the front of every response.

The query builder intentionally prioritizes featured listings only for the default ordering (Date, ascending, with an open or all status). The API route previously called reorderFeaturedOngoing for every request after Prisma had applied the requested order. That second pass could silently override explicit Prize, Submissions, Status, and descending Date sorts.

This PR extracts the existing default-sort rule into shouldPrioritizeFeatured and uses the same predicate in both places:

• the Prisma orderBy construction
• the response-level pass that keeps expired or completed featured listings from being promoted

Custom sorts now retain the database order, while the existing default featured-listing behavior remains unchanged.

Where should the reviewer start?

1. src/features/listings/utils/query-builder.ts — the shared shouldPrioritizeFeatured rule and its use in getOrderBy
2. src/app/api/listings/route.ts — conditional response reordering

How should this be manually tested?

1. Open the listings page with status set to Open.
2. Select Prize ascending and confirm a higher-value featured listing no longer jumps ahead of lower-value listings.
3. Repeat with Submissions, Status, and Date descending; each result should follow the selected order.
4. Return to the default Date ascending sort and confirm ongoing featured listings are still prioritized.
5. With status set to All, confirm expired or completed featured listings are not promoted by the response-level reorder.

Validation performed locally:

• pnpm check-types — passed
• pnpm lint — completed with 0 errors
• pnpm exec oxfmt --check src/app/api/listings/route.ts src/features/listings/utils/query-builder.ts — passed
• git diff --check — passed

Any background context you want to provide?

The mismatch existed because the database layer and response layer independently decided whether featured listings should be prioritized. Centralizing that decision prevents the two layers from drifting again.

What are the relevant issues?

No linked issue. This was found while auditing the current listing query and response ordering paths. Existing open issues and pull requests were checked for overlap before implementation.

Screenshots (if appropriate)

Not applicable; this is an API ordering correction with no visual layout changes.

Summary by CodeRabbit

• Bug Fixes
  • Featured ongoing listings are now prioritized only when the default sorting and status filters are selected.
  • Results preserve the requested database order for other sorting and filtering combinations.
  • Listing order behavior is now more consistent across different search criteria.

[vercel]

@iamomm-hack is attempting to deploy a commit to the Superteam Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 941dbdbb-0947-47e4-9808-f8adb3fdba0a

📥 Commits

Reviewing files that changed from the base of the PR and between 092e846 and 4e4885a.

📒 Files selected for processing (2)

• src/app/api/listings/route.ts
• src/features/listings/utils/query-builder.ts

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

Walkthrough

The query builder now centralizes detection of default featured-prioritized sorting. The listings API reorders featured ongoing listings only for matching queries and preserves database order for other queries.

Changes

Featured listing ordering

Layer / File(s)	Summary
Centralize prioritization detection src/features/listings/utils/query-builder.ts	The exported shouldPrioritizeFeatured helper detects Date ascending queries with open or all status. getOrderBy uses this helper.
Apply conditional route ordering src/app/api/listings/route.ts	The listings route imports the helper, conditionally calls reorderFeaturedOngoing, and returns the resulting orderedListings list.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 4e488

This change preserves explicitly selected listing sort orders while retaining the existing default featured-listing behavior. No actionable merge-blocking risk remains beyond normal checks and review.

Poem

A rabbit checks the sorting trail
Featured listings lead when rules prevail
Other results keep their place
The query helper sets the pace
Clean responses hop without fail

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: preserving users’ explicit listing sort order while retaining default featured-listing prioritization.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}