Order topics deterministically in serialization queryset - #3765
Open
mbertrand wants to merge 3 commits into
Open
Order topics deterministically in serialization queryset#3765mbertrand wants to merge 3 commits into
mbertrand wants to merge 3 commits into
Conversation
LearningResourceTopic has no Meta.ordering, so the topics prefetch and the test's own expected values came back in whatever order Postgres chose, making test_serialize_bulk_learning_resources flake. Ordering by name also makes topic order stable in API responses. Fixes mitodl/hq#12833 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenAPI ChangesNo changes detected Unexpected changes? Ensure your branch is up-to-date with |
Contributor
There was a problem hiding this comment.
Pull request overview
Makes serialized topic ordering deterministic, preventing intermittent test and API ordering differences.
Changes:
- Orders serialization topics alphabetically by name.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The bulk-serialization test builds both its expected and actual topic lists through this queryset, so it can't independently pin the ordering. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…yset Ordering only for_serialization() left the plain related manager unordered, and serializers use both: ContentFileSerializer.get_topics() reads learning_resource.topics directly while the API queryset prefetches through for_serialization(). The two disagreed, breaking test_learning_resource_serializer and test_get_contentfiles_detail_endpoint. Meta.ordering covers every path, matching what LearningResourceDepartment already does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
What are the relevant tickets?
Closes https://github.com/mitodl/hq/issues/12833
Description (What does it do?)
LearningResourceTopichad noMeta.ordering, so topics came back in whatever order Postgres chose.test_serialize_bulk_learning_resourcesbuilds its expected values from one query and the serializer builds its results from another, so the two disagreed intermittently. Addingordering = ["name"]to the model makes topic order deterministic in the test and in API responses — same thingLearningResourceDepartmentalready does.How can this be tested?
Should pass every time