Skip to content

fix(reranker): _process_response never actually sorts results by score - #52

Closed
mittalpk wants to merge 1 commit into
cloudflare:mainfrom
mittalpk:fix/reranker-process-response-never-sorts
Closed

mittalpk wants to merge 1 commit into
cloudflare:mainfrom
mittalpk:fix/reranker-process-response-never-sorts

Conversation

@mittalpk

@mittalpk mittalpk commented Aug 16, 2026 •

Copy link
Copy Markdown
Contributor

Every docstring on CloudflareWorkersAIReranker (rerank(), arerank(), and _process_response() itself) promises results sorted by relevance score descending, but the implementation just appended results in whatever order the API response listed them — no sort() call anywhere, and nothing in the test suite exercised this.

Tested against the live Workers AI API directly: the default model (@cf/baai/bge-reranker-base) does already return results sorted by score, so this isn't causing wrong output for the default model today. But the code shouldn't depend on an undocumented assumption about API/model behavior — the sort is one line, and it's what the docstrings already promise regardless of what a given model happens to do.

Added the sort plus two tests (an out-of-order response and an already-sorted one). Full unit suite: 138 passed, 2 skipped, 0 regressions.

Every docstring on this reranker (rerank(), arerank(), and
_process_response() itself) promises results "sorted by relevance
score (descending)", but the implementation just appended results in
whatever order the API response listed them -- no sort() call
anywhere. Nothing in the test suite exercised this at all; the only
existing tests cover credential validation.

Added the sort and two tests covering both an out-of-order response
and an already-sorted one.
@CollierKing

Copy link
Copy Markdown
Collaborator

Thank you for this — good catch that every docstring promised score-descending order but nothing actually enforced it, plus solid test coverage for both the out-of-order and already-sorted cases.

This fix has been incorporated into #53, which just merged into main (commit 9437e4c). Closing this in favor of that — appreciate the contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants