✨(backend) Order pinned documents by last updated at

[pvrnn]

Purpose

• Closes Order pinned documents by date of last_update #1962

Recording.2026-03-16.202548.1.mp4

Proposal

• Use queryset to sort favorite documents by last updated_at date.

External contributions

Thank you for your contribution! 🎉

Please ensure the following items are checked before submitting your pull request:

• I have read and followed the contributing guidelines
• I have read and agreed to the Code of Conduct
• I have signed off my commits with git commit --signoff (DCO compliance)
• I have signed my commits with my SSH or GPG key (git commit -S)
• My commit messages follow the required format: <gitmoji>(type) title description
• I have added a changelog entry under ## [Unreleased] section (if noticeable change)
• I have added corresponding tests for new features or bug fixes (if applicable)

[coderabbitai]

Walkthrough

This PR implements ordering of favorite (pinned) documents by their updated_at timestamp in descending order. The change adds an explicit .order_by('-updated_at') clause to the DocumentViewSet.favorite_list queryset. The CHANGELOG is updated to document this feature, and test coverage is enhanced with an existing test assertion updated and a new test added to verify that favorites are returned in the correct order by modification date.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: ordering pinned documents by their last update date in the backend.
Description check	✅ Passed	The description is directly related to the changeset, explaining the purpose, referencing the closed issue (#1962), and confirming all required checklist items.
Linked Issues check	✅ Passed	The PR successfully implements the core requirement from issue #1962: ordering pinned documents by last_updated_at in descending order via queryset modifications and corresponding tests.
Out of Scope Changes check	✅ Passed	All changes are directly related to the sorting requirement. The CHANGELOG update documents the change, viewsets.py implements the sorting logic, and tests validate the new behavior.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 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 and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/backend/core/tests/documents/test_api_documents_favorite_list.py`:
- Around line 118-120: The test test_api_documents_favorite_list currently
asserts strict ordering on content by checking content[0], content[1],
content[2], which can be flaky because timestamps may collide; change these
assertions to verify membership only (e.g., compare sets of IDs or use assertIn
for each expected id) so the test asserts that the expected document ids
(access.document.id and children[0].id/children[1].id) are present in the
response without assuming order.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: bcd70718-9add-45e7-a5c5-28d6af67cd6f

📥 Commits

Reviewing files that changed from the base of the PR and between 1ebdda8 and ace831d.

📒 Files selected for processing (3)

• CHANGELOG.md
• src/backend/core/api/viewsets.py
• src/backend/core/tests/documents/test_api_documents_favorite_list.py

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Avoid strict ordering assertions in the non-order-specific test.

This test now asserts exact index order without controlling timestamps, so it can become flaky when updated_at values collide. Since ordering is already validated in test_api_document_favorite_list_sorted_by_updated_at, this test should only verify membership.

✅ Suggested test stabilization

-    assert content[0]["id"] == str(access.document.id)
-    assert content[1]["id"] == str(children[1].id)
-    assert content[2]["id"] == str(children[0].id)
+    ids = {item["id"] for item in content}
+    assert ids == {
+        str(access.document.id),
+        str(children[0].id),
+        str(children[1].id),
+    }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	assert content[0]["id"] == str(access.document.id)
	assert content[1]["id"] == str(children[1].id)
	assert content[2]["id"] == str(children[0].id)
	ids = {item["id"] for item in content}
	assert ids == {
	str(access.document.id),
	str(children[0].id),
	str(children[1].id),
	}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/backend/core/tests/documents/test_api_documents_favorite_list.py` around
lines 118 - 120, The test test_api_documents_favorite_list currently asserts
strict ordering on content by checking content[0], content[1], content[2], which
can be flaky because timestamps may collide; change these assertions to verify
membership only (e.g., compare sets of IDs or use assertIn for each expected id)
so the test asserts that the expected document ids (access.document.id and
children[0].id/children[1].id) are present in the response without assuming
order.