Standardize release notes and migration naming. by Innavin369 · Pull Request #676 · opensupplyhub/open-supply-hub

Innavin369 · 2025-07-03T20:53:52Z

In the scope of these changes, the following has been done:

removed empty sections (excluding last 2.8.0)
added .py extension to migration file names
removed semicolumn from section names Migrations and Release instructions

barecheck · 2025-07-03T20:56:31Z

React App | Jest test suite - Code coverage report

Total: 34.44%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

coderabbitai · 2025-07-03T20:59:02Z

📝 Walkthrough

Walkthrough

This update standardizes migration filenames in the release notes by appending the .py extension, removes empty placeholder sections, and improves formatting. Additionally, it removes a redundant import in a serializer file and adds blank lines for formatting in a view function. No functional or behavioral changes to the codebase are introduced.

Changes

File(s)	Change Summary
doc/release/RELEASE-NOTES.md	Standardized migration filenames with `.py` extension, removed empty sections, improved formatting
src/django/api/serializers/log_download_query_params.py	Removed a redundant import statement
src/django/api/views/log_download.py	Added blank lines for formatting around a variable assignment

Possibly related PRs

[OSDEV-2016] Prepare release notes for v.2.6.0 #647: Updates release notes documentation by removing empty sections and improving formatting.
Remove template text from release notes before the release 2.4 #618: Removes placeholder or empty sections from release notes to clean up content before a release.
added new release version to release notes, replace task, removed emp… #486: Modifies release notes to update content, remove empty sections, and adjust formatting.

Suggested reviewers

mazursasha1990
VadimKovalenkoSNF
roman-stolar

✨ Finishing Touches

📝 Generate Docstrings

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Explain this complex logic.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai explain this code block.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and explain its main purpose.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (5)

src/django/api/tests/test_log_download.py (1)
66-96: Good test coverage, but make error message dynamic.

The test effectively covers both boundary conditions for path length validation. However, consider making the expected error message dynamic to maintain consistency with the validation logic.

Apply this diff to make the error message dynamic:
-        expected_error = "Path length must not exceed 4096 characters."
+        expected_error = f"Path length must not exceed {max_length} characters."
This ensures the test remains valid if the max_length changes in the future.
doc/release/RELEASE-NOTES.md (4)
15-17: Normalize bullet-point indentation

The newly-added migration entry is indented two spaces fewer than the surrounding list (lines 15-17 vs. the rest of the document). This breaks Markdown bullet alignment and triggers MD007 warnings.
-* 0172_increase_path_max_length.py - The migration increases `max_length` for the `path` field in the `DownloadLog` model.
+  * 0172_increase_path_max_length.py – Increases `max_length` of `DownloadLog.path` to 4096.
28-33: Keep bullet hierarchy consistent

Within “Bugfix” the second-level list (31-32) is aligned at the same column as the first-level items, so Markdown renders both as top-level bullets. Add two spaces of indent to make them true children.
-    * Adjusted the post-submit popup. …
-    * [OSDEV-1913] – The `max_length` …
+      * Adjusted the post-submit popup. …
+      * [OSDEV-1913] – The `max_length` …
50-50: Fix heading level jump (MD001)

#### Migrations jumps from an ## section directly to ####.
Use ### so heading levels increase by exactly one.
-#### Migrations
+### Migrations
132-136: Release-instructions heading should be ###

Same heading-level issue under 2.7.0 (and later sections).
Align all “Release instructions” headers to ###.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d25df1a and 7945748.

📒 Files selected for processing (6)

doc/release/RELEASE-NOTES.md (60 hunks)
src/django/api/migrations/0172_increase_path_max_length.py (1 hunks)
src/django/api/models/download_log.py (1 hunks)
src/django/api/serializers/log_download_query_params.py (1 hunks)
src/django/api/tests/test_log_download.py (1 hunks)
src/django/api/views/log_download.py (1 hunks)

🧰 Additional context used

🧠 Learnings (5)

📓 Common learnings

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#641
File: doc/release/RELEASE-NOTES.md:6-35
Timestamp: 2025-06-02T13:24:57.659Z
Learning: The Open Supply Hub team keeps placeholders in release notes until code freeze, then fills in the actual content once all changes are finalized for the release.

Learnt from: roninzp
PR: opensupplyhub/open-supply-hub#636
File: scripts/check_release_branch.sh:7-12
Timestamp: 2025-05-27T11:11:57.522Z
Learning: In the open-supply-hub repository, release branches use the naming pattern "releases/*" (with an "s"), not "release/*". The script check_release_branch.sh correctly uses this pattern.

Learnt from: Innavin369
PR: opensupplyhub/open-supply-hub#642
File: src/django/api/models/facility_download_limit.py:64-73
Timestamp: 2025-06-18T12:46:27.549Z
Learning: The validation checks in FacilitiesDownloadViewSet.list method in src/django/api/facilities_download_view_set.py are insufficient to prevent register_download from receiving more records than the user's available quota. The method only validates against zero total quota on first page and global limits, but doesn't validate records_returned against remaining user quota before calling register_download.

Learnt from: Innavin369
PR: opensupplyhub/open-supply-hub#642
File: src/django/api/facilities_download_view_set.py:115-119
Timestamp: 2025-06-17T10:55:08.363Z
Learning: In the FacilitiesDownloadViewSet.list method in src/django/api/facilities_download_view_set.py, the existing validation checks do not prevent paid_download_records from going negative. The validation only checks if the user has zero total quota (free + paid == 0) on the first page, and if the total query results exceed the global limit of 5000, but does not validate the user's remaining quota against the actual records_to_subtract value which is calculated after pagination.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/serializers/v1/opensearch_common_validators/moderation_id_validator.py:20-25
Timestamp: 2024-11-13T07:21:28.686Z
Learning: In the `ModerationIdValidator` class located at `src/django/api/serializers/v1/opensearch_common_validators/moderation_id_validator.py`, it's not necessary to add input size validation for the `moderation_id` list. OpenSearch already imposes a page size limit, which mitigates potential DoS attacks from large inputs.

src/django/api/views/log_download.py (2)

Learnt from: Innavin369
PR: opensupplyhub/open-supply-hub#642
File: src/django/api/facilities_download_view_set.py:115-119
Timestamp: 2025-06-17T10:55:08.363Z
Learning: In the FacilitiesDownloadViewSet.list method in src/django/api/facilities_download_view_set.py, the existing validation checks do not prevent paid_download_records from going negative. The validation only checks if the user has zero total quota (free + paid == 0) on the first page, and if the total query results exceed the global limit of 5000, but does not validate the user's remaining quota against the actual records_to_subtract value which is calculated after pagination.

Learnt from: Innavin369
PR: opensupplyhub/open-supply-hub#642
File: src/django/api/models/facility_download_limit.py:64-73
Timestamp: 2025-06-18T12:46:27.549Z
Learning: The validation checks in FacilitiesDownloadViewSet.list method in src/django/api/facilities_download_view_set.py are insufficient to prevent register_download from receiving more records than the user's available quota. The method only validates against zero total quota on first page and global limits, but doesn't validate records_returned against remaining user quota before calling register_download.

src/django/api/serializers/log_download_query_params.py (10)

Learnt from: mazursasha1990
PR: opensupplyhub/open-supply-hub#488
File: src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py:114-119
Timestamp: 2025-01-29T08:51:47.803Z
Learning: In the Open Supply Hub codebase, request parameter validation is handled in the serializer layer through:
1. Field-level validation using DRF fields (e.g., IntegerField, CharField)
2. Custom validator classes (e.g., SizeValidator which enforces a maximum limit of 250 records)
Adding validation in query builders or directors would be redundant as it's already handled by the serializer layer.

Learnt from: Innavin369
PR: opensupplyhub/open-supply-hub#642
File: src/django/api/models/facility_download_limit.py:64-73
Timestamp: 2025-06-18T12:46:27.549Z
Learning: The validation checks in FacilitiesDownloadViewSet.list method in src/django/api/facilities_download_view_set.py are insufficient to prevent register_download from receiving more records than the user's available quota. The method only validates against zero total quota on first page and global limits, but doesn't validate records_returned against remaining user quota before calling register_download.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/serializers/v1/opensearch_common_validators/moderation_id_validator.py:20-25
Timestamp: 2024-11-13T07:21:28.686Z
Learning: In the `ModerationIdValidator` class located at `src/django/api/serializers/v1/opensearch_common_validators/moderation_id_validator.py`, it's not necessary to add input size validation for the `moderation_id` list. OpenSearch already imposes a page size limit, which mitigates potential DoS attacks from large inputs.

Learnt from: Innavin369
PR: opensupplyhub/open-supply-hub#642
File: src/django/api/facilities_download_view_set.py:115-119
Timestamp: 2025-06-17T10:55:08.363Z
Learning: In the FacilitiesDownloadViewSet.list method in src/django/api/facilities_download_view_set.py, the existing validation checks do not prevent paid_download_records from going negative. The validation only checks if the user has zero total quota (free + paid == 0) on the first page, and if the total query results exceed the global limit of 5000, but does not validate the user's remaining quota against the actual records_to_subtract value which is calculated after pagination.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/moderation_events.py:41-43
Timestamp: 2024-11-12T11:42:07.768Z
Learning: In the `ModerationEvents` API endpoint, parameter validation is handled in `src/django/api/serializers/v1/moderation_events_serializer.py`.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py:12-13
Timestamp: 2024-11-14T11:06:35.337Z
Learning: In `src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py`, input validation for methods like `add_from` is performed at a higher level, so additional validation within these methods is unnecessary.

Learnt from: mazursasha1990
PR: opensupplyhub/open-supply-hub#488
File: src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py:114-119
Timestamp: 2025-01-29T08:51:47.803Z
Learning: In the Open Supply Hub codebase, request parameter validation is handled in the serializer layer through:
1. Field-level validation using DRF fields (e.g., IntegerField, CharField)
2. Custom validator classes (e.g., SizeValidator)
Adding validation in query builders or directors would be redundant as it's already handled by the serializer layer.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/serializers/v1/opensearch_common_validators/date_range_validator.py:9-11
Timestamp: 2024-11-12T11:15:04.794Z
Learning: In `src/django/api/serializers/v1/opensearch_common_validators/date_range_validator.py`, date format validation is not required within the `DateRangeValidator` class, as date validation is handled elsewhere in the codebase.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#420
File: src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py:87-92
Timestamp: 2024-11-26T12:24:22.563Z
Learning: In the Open Supply Hub codebase, validation for parameters such as `order_by` is performed in the serializers, specifically in `src/django/api/serializers/v1/moderation_events_serializer.py`, so validation is not needed in the query builder methods like `add_sort`.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py:61-79
Timestamp: 2024-11-14T11:06:37.772Z
Learning: In the `OpenSearchQueryBuilder` class located at `src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py`, date validation is performed at a higher level in the application. Therefore, it's unnecessary to add additional date validation within the `__build_date_range` method.

src/django/api/tests/test_log_download.py (1)

Learnt from: mazursasha1990
PR: opensupplyhub/open-supply-hub#438
File: src/django/api/tests/test_moderation_events_add_production_location.py:21-65
Timestamp: 2024-12-12T14:59:19.694Z
Learning: In `src/django/api/tests/test_moderation_events_add_production_location.py`, the tests have been refactored, and the use of `POST` methods is intentional. Future suggestions to change HTTP methods in these tests may not be necessary.

doc/release/RELEASE-NOTES.md (23)

undefined

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #420
File: doc/release/RELEASE-NOTES.md:38-38
Timestamp: 2024-11-26T04:59:12.296Z
Learning: For endpoints that haven't been released to end users, it's acceptable to document API changes under the 'Bugfix' section in the release notes.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #420
File: doc/release/RELEASE-NOTES.md:47-54
Timestamp: 2024-11-28T06:36:47.122Z
Learning: API changes and migration details are documented in a separate repository with API specifications, rather than in the release notes.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #420
File: doc/release/RELEASE-NOTES.md:47-54
Timestamp: 2024-11-28T06:36:47.122Z
Learning: Endpoints that have not been enabled to end users do not require migration documentation or old vs new format examples in the release notes.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #641
File: doc/release/RELEASE-NOTES.md:6-35
Timestamp: 2025-06-02T13:24:57.659Z
Learning: The Open Supply Hub team keeps placeholders in release notes until code freeze, then fills in the actual content once all changes are finalized for the release.
</retrieved_learning>

<retrieved_learning>
Learnt from: Innavin369
PR: #431
File: src/django/api/serializers/v1/opensearch_common_validators/countries_validator.py:23-24
Timestamp: 2024-11-28T11:29:28.139Z
Learning: The files src/django/api/tests/test_facility_claim_view_set.py, src/django/api/views/facility/facilities_view_set.py, and src/django/api/facility_actions/processing_facility_api.py are not part of the V1 codebase in the Open Supply Hub project.
</retrieved_learning>

<retrieved_learning>
Learnt from: vladsha-dev
PR: #490
File: deployment/environments/terraform-preprod.tfvars:17-18
Timestamp: 2025-01-29T13:36:47.477Z
Learning: In the Open Supply Hub project, the pre-prod environment is always created from scratch, so PostgreSQL version upgrade flags (rds_allow_major_version_upgrade and rds_apply_immediately) are not needed as there's no upgrade process involved. These flags should only be set for environments that are being upgraded from an existing PostgreSQL 13 instance (e.g., Staging, Production, Dev, Test).
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #420
File: doc/release/RELEASE-NOTES.md:37-37
Timestamp: 2024-11-25T13:28:23.090Z
Learning: When modifying unreleased API endpoints, such as refactoring the search_after parameter into search_after_value and search_after_id in the OpenSearch implementation, it's acceptable to leave the "What's New" section empty since the changes haven't been released to end users.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #646
File: src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py:130-134
Timestamp: 2025-06-10T13:52:52.755Z
Learning: For OpenSearch queries in the opensearch_query_director.py file, different query types require different character thresholds: multi_match queries should use a 50-character threshold while regular match queries use a 180-character threshold. The multi_match functionality becomes less effective with longer strings, so 180 characters would be too much for the query parameter powered by multi_match.
</retrieved_learning>

<retrieved_learning>
Learnt from: roman-stolar
PR: #536
File: src/django/api/views/v1/moderation_events.py:195-196
Timestamp: 2025-02-28T08:20:33.579Z
Learning: In the update_production_location method of the ModerationEvents class, no additional check for event.status is needed before sending the approval email with send_slc_contribution_approval_email as the method's flow already ensures appropriate validation.
</retrieved_learning>

<retrieved_learning>
Learnt from: mazursasha1990
PR: #438
File: src/django/api/views/v1/moderation_events.py:140-142
Timestamp: 2024-12-13T13:20:48.143Z
Learning: In the Open Supply Hub codebase, it's acceptable to catch broad exceptions in methods like add_production_location and update_production_location in src/django/api/views/v1/moderation_events.py instead of catching specific exceptions.
</retrieved_learning>

<retrieved_learning>
Learnt from: Innavin369
PR: #415
File: src/django/api/management/commands/enable_switches.py:15-15
Timestamp: 2024-11-20T23:12:50.325Z
Learning: In src/django/api/management/commands/enable_switches.py, setting 'disable_list_uploading' to 'off' is intentional to enable list uploading outside of the release process.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #391
File: src/django/api/migrations/0159_alter_status_of_moderation_event_table.py:13-18
Timestamp: 2024-11-12T09:09:53.738Z
Learning: Currently, the moderationevent table has no existing records, so data migrations to handle changes in the status field are unnecessary.
</retrieved_learning>

<retrieved_learning>
Learnt from: mazursasha1990
PR: #438
File: src/django/api/tests/test_moderation_events_add_production_location.py:21-65
Timestamp: 2024-12-12T14:59:19.694Z
Learning: In src/django/api/tests/test_moderation_events_add_production_location.py, the tests have been refactored, and the use of POST methods is intentional. Future suggestions to change HTTP methods in these tests may not be necessary.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #376
File: src/django/api/models/moderation_event.py:60-66
Timestamp: 2024-10-22T11:36:59.787Z
Learning: In the ModerationEvent model in src/django/api/models/moderation_event.py, setting on_delete=models.SET_NULL for the claim field is expected behavior.
</retrieved_learning>

<retrieved_learning>
Learnt from: mazursasha1990
PR: #400
File: src/django/api/views/v1/moderation_events.py:150-155
Timestamp: 2024-11-21T13:02:50.316Z
Learning: In the src/django/api/views/v1/moderation_events.py file, when the moderation event status is not PENDING, the appropriate HTTP status code to return is 410 GONE according to the project's requirements.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #391
File: src/django/api/views/v1/moderation_events.py:47-51
Timestamp: 2024-11-13T07:19:10.746Z
Learning: In the ModerationEvents view in src/django/api/views/v1/moderation_events.py, adding next and previous links to API responses is outside the current scope and does not conform to the current specifications.
</retrieved_learning>

<retrieved_learning>
Learnt from: roman-stolar
PR: #405
File: src/django/api/views/v1/moderation_events.py:69-85
Timestamp: 2024-11-14T14:45:44.813Z
Learning: The ModerationEvent model does not include a user_id field.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #391
File: src/django/api/views/v1/moderation_events.py:41-43
Timestamp: 2024-11-12T11:42:07.768Z
Learning: In the ModerationEvents API endpoint, parameter validation is handled in src/django/api/serializers/v1/moderation_events_serializer.py.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #391
File: src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py:48-0
Timestamp: 2024-11-12T09:11:37.543Z
Learning: In the ModerationEventsQueryBuilder class (src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py), methods inherited from the parent class OpenSearchQueryBuilder, such as _build_os_id, are available and can be used without redefining them.
</retrieved_learning>

<retrieved_learning>
Learnt from: Innavin369
PR: #476
File: src/react/src/components/ResultsSortDropdown.jsx:60-88
Timestamp: 2025-01-09T17:22:47.297Z
Learning: In the Open Supply Hub project, the sorting functionality's page-specific behavior is controlled at the routing level (withQueryStringSync.jsx) rather than through UI state management. The ResultsSortDropdown component remains consistently rendered across pages, while the sort parameter is only maintained in the URL when on the /facilities page.
</retrieved_learning>

<retrieved_learning>
Learnt from: Innavin369
PR: #415
File: src/react/src/components/ContributeForm.jsx:184-190
Timestamp: 2024-11-22T12:24:03.226Z
Learning: In the Open Supply Hub project, code quality improvements like adding missing prop type validations can be deferred to future improvements tasks.
</retrieved_learning>

<retrieved_learning>
Learnt from: mazursasha1990
PR: #438
File: src/django/api/tests/test_moderation_events_add_production_location.py:27-30
Timestamp: 2024-12-17T15:59:02.112Z
Learning: In tests for the PATCH endpoint /api/v1/moderation-events/{moderation_id}/production-locations/, it's acceptable to use POST requests in the tests.
</retrieved_learning>

<retrieved_learning>
Learnt from: VadimKovalenkoSNF
PR: #578
File: src/django/api/serializers/facility/facility_create_claim_serializer.py:20-26
Timestamp: 2025-04-11T05:31:54.895Z
Learning: In the Open Supply Hub project, the validate_workers function in facility claim serializers intentionally returns None for invalid worker counts rather than raising validation errors, as this behavior aligns with the project's business logic.
</retrieved_learning>

🧬 Code Graph Analysis (3)

src/django/api/views/log_download.py (1)

src/django/api/constants.py (1)

LogDownloadQueryParams (147-149)

src/django/api/serializers/log_download_query_params.py (1)

src/django/api/models/download_log.py (1)

DownloadLog (4-24)

src/django/api/tests/test_log_download.py (2)

src/django/api/models/download_log.py (1)

DownloadLog (4-24)

src/django/api/constants.py (1)

LogDownloadQueryParams (147-149)

🪛 Pylint (3.3.7)

src/django/api/serializers/log_download_query_params.py

[refactor] 11-11: Too few public methods (1/2)

(R0903)

src/django/api/migrations/0172_increase_path_max_length.py

[refactor] 6-6: Too few public methods (0/2)

(R0903)

🪛 markdownlint-cli2 (0.17.2)

doc/release/RELEASE-NOTES.md

31-31: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

50-50: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

229-229: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

267-267: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

342-342: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

653-653: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

730-730: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

814-814: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

839-839: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

929-929: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1013-1013: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1056-1056: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1108-1108: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1153-1153: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1205-1205: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1253-1253: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1364-1364: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1415-1415: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1527-1527: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1529-1529: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1529-1529: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

1530-1530: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1530-1530: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

1583-1583: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1584-1584: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1600-1600: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1609-1609: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

1610-1610: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1611-1611: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1612-1612: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1613-1613: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1661-1661: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1662-1662: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

1663-1663: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

⏰ Context from checks skipped due to timeout of 90000ms (13)

GitHub Check: run-integration-test-code-quality
GitHub Check: run-contricleaner-code-quality
GitHub Check: run-flake8-linter
GitHub Check: get-base-branch-dd-cov
GitHub Check: get-base-branch-contricleaner-cov
GitHub Check: run-eslint-linter-and-prettier-formatter
GitHub Check: run-dd-code-quality
GitHub Check: get-base-branch-countries-cov
GitHub Check: run-countries-code-quality
GitHub Check: run-fe-code-quality
GitHub Check: run-django-code-quality
GitHub Check: get-base-branch-django-cov
GitHub Check: get-base-branch-fe-cov

🔇 Additional comments (6)

src/django/api/views/log_download.py (1)

27-31: LGTM! Good formatting improvement.

The added blank lines improve code readability without affecting functionality.

src/django/api/migrations/0172_increase_path_max_length.py (1)

6-18: LGTM! Migration is correctly structured.

The migration properly increases the path field max_length from 2083 to 4096 characters and follows Django migration conventions.

src/django/api/models/download_log.py (1)

14-18: LGTM! Model field update is correct.

The increase in path field max_length from 2083 to 4096 characters is properly implemented and aligns with the corresponding migration.

src/django/api/serializers/log_download_query_params.py (3)

1-1: LGTM! Proper import for validation.

The ValidationError import is correctly added to support the custom validation method.

8-8: LGTM! Appropriate model import.

The DownloadLog model import is correctly added to access the field metadata for validation.

15-22: LGTM! Excellent validation implementation.

The custom validation method follows best practices:

Dynamically retrieves max_length from the model to ensure consistency

Provides clear error messaging

Follows Django REST Framework's validation pattern

This approach ensures that any future changes to the model field's max_length will be automatically reflected in the validation logic.

barecheck · 2025-07-03T21:00:54Z

Dedupe Hub App | Unittest test suite - Code coverage report

Total: 55.73%

Your code coverage diff: 0.00% ▴

✅ All code changes are covered

coderabbitai

Actionable comments posted: 1

🧹 Nitpick comments (1)

doc/release/RELEASE-NOTES.md (1)
1555-1575: Inconsistent bulleted-list markers trigger markdown-lint noise

Several new bullets use a dash (-) while the surrounding release notes consistently use an asterisk (*).
The mixed style violates the repo’s markdownlint rules (see MD004, MD007 hints) and pollutes CI logs.
- - apply migrations up to 0130_facility_index_gin_index.py
+ * apply migrations up to 0130_facility_index_gin_index.py
Apply the same change to every newly-added - bullet to keep the file lint-clean.

Also applies to: 1620-1635, 1650-1660, 1690-1705

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7945748 and 34f33f7.

📒 Files selected for processing (2)

doc/release/RELEASE-NOTES.md (59 hunks)
src/django/api/serializers/log_download_query_params.py (1 hunks)

🧰 Additional context used

🧠 Learnings (3)

📓 Common learnings

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#641
File: doc/release/RELEASE-NOTES.md:6-35
Timestamp: 2025-06-02T13:24:57.659Z
Learning: The Open Supply Hub team keeps placeholders in release notes until code freeze, then fills in the actual content once all changes are finalized for the release.

Learnt from: roninzp
PR: opensupplyhub/open-supply-hub#636
File: scripts/check_release_branch.sh:7-12
Timestamp: 2025-05-27T11:11:57.522Z
Learning: In the open-supply-hub repository, release branches use the naming pattern "releases/*" (with an "s"), not "release/*". The script check_release_branch.sh correctly uses this pattern.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#420
File: doc/release/RELEASE-NOTES.md:47-54
Timestamp: 2024-11-28T06:36:47.122Z
Learning: API changes and migration details are documented in a separate repository with API specifications, rather than in the release notes.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#420
File: doc/release/RELEASE-NOTES.md:47-54
Timestamp: 2024-11-28T06:36:47.122Z
Learning: Endpoints that have not been enabled to end users do not require migration documentation or old vs new format examples in the release notes.

Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#420
File: doc/release/RELEASE-NOTES.md:38-38
Timestamp: 2024-11-26T04:59:12.296Z
Learning: For endpoints that haven't been released to end users, it's acceptable to document API changes under the 'Bugfix' section in the release notes.

doc/release/RELEASE-NOTES.md (24)