Conventional dataset tag - #359
Conversation
WalkthroughAdds Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Consider returning a more semantically appropriate status code (e.g., 204 No Content) from the new
POST /datasets/{identifier}/tagsendpoint instead of200with anullbody, since no response payload is provided. - The deprecated
tag_datasethandler now calls the newtag_dataset_newroute function directly; it would be cleaner to extract the shared tagging logic into a separate helper/service function that both endpoints call to avoid coupling between router handlers.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider returning a more semantically appropriate status code (e.g., 204 No Content) from the new `POST /datasets/{identifier}/tags` endpoint instead of `200` with a `null` body, since no response payload is provided.
- The deprecated `tag_dataset` handler now calls the new `tag_dataset_new` route function directly; it would be cleaner to extract the shared tagging logic into a separate helper/service function that both endpoints call to avoid coupling between router handlers.
## Individual Comments
### Comment 1
<location path="docs/migration.md" line_range="136" />
<code_context>
+???+ warning "This endpoint is deprecated"
+
+ The new tag endpoint is `POST` `/datasets/{identifier}/tags`.
+ The dataset identifier is provided as part of the path, the tag is still provided in the body.
+ This endpoint is provided for easier migration in case the response matters to you.
+
</code_context>
<issue_to_address>
**issue (typo):** Fix the comma splice between the two independent clauses.
You can fix this by replacing the comma with "and", using a semicolon, or splitting it into two sentences.
```suggestion
The dataset identifier is provided as part of the path and the tag is still provided in the body.
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #359 +/- ##
==========================================
- Coverage 94.65% 94.64% -0.01%
==========================================
Files 77 77
Lines 3815 3827 +12
Branches 248 248
==========================================
+ Hits 3611 3622 +11
Misses 137 137
- Partials 67 68 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/migration.md (1)
135-137: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDocument the replacement request body explicitly.
The new endpoint requires an embedded payload such as
{"tag": "foo"}; showing this example would prevent clients from carrying over the legacydata_idfield during migration.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/migration.md` around lines 135 - 137, Update the migration documentation describing the POST /datasets/{identifier}/tags endpoint to explicitly show the replacement request body, using a payload example with the tag field such as {"tag": "foo"} and omitting the legacy data_id field.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@docs/migration.md`:
- Around line 135-137: Update the migration documentation describing the POST
/datasets/{identifier}/tags endpoint to explicitly show the replacement request
body, using a payload example with the tag field such as {"tag": "foo"} and
omitting the legacy data_id field.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 412be693-b754-4414-adab-161cbc1fdad6
📒 Files selected for processing (4)
docs/migration.mddocs/roadmap.mdsrc/routers/datasets.pytests/routers/dataset_tag_test.py
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/routers/datasets.py`:
- Line 112: Update test_dataset_tag_new_json to expect HTTPStatus.NO_CONTENT for
the dataset tags endpoint and verify the response body is empty, removing the
response.json() assertion because a 204 response has no JSON payload.
🪄 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 Plus
Run ID: a321a955-6235-48ba-8df3-c59bb324983b
📒 Files selected for processing (1)
src/routers/datasets.py
affb186 to
fc10705
Compare
fc10705 to
4b5914d
Compare
| ) | ||
| async def test_dataset_tag_rejects_unauthorized(key: ApiKey, py_api: httpx.AsyncClient) -> None: | ||
| apikey = "" if key is None else f"?api_key={key}" | ||
| async def test_dataset_tag_requires_authorization(py_api: httpx.AsyncClient) -> None: |
There was a problem hiding this comment.
The various variants of not authenticating correctly should be delegated to tests for the get_user_or_raise dependency. Just including the unauthenticated case in the endpoint specific test is enough to ensure that the dependency is present.
Though even that I am not entirely sure if we should include a test for. It should be easy enough to detect changes of function signature in reviews.
|
|
||
| ### Datasets | ||
|
|
||
| #### `GET /{dataset_id}` |
There was a problem hiding this comment.
Is this meant as /datasets/{dataset_id} rather than /{dataset_id}?
/data/list/filters is specified in full below, so I'm assuming anything listed in this doc is a full path.
If that's the case, shouldn't it be /datasets/{dataset_id} and data/list/filters should also be made /datasets/list/filters with all dataset-related endpoints being under /datasets?
|
I agree that this is a change that doesn't require much overhead; however, I'm still hesitant about adhoc design migrations versus a systematic decision. I believe this is something which should be decided upfront. Then we can choose if all data-relevant endpoints are My suggestion is for us to have the design conversations first and agree on a path. Happy to do that. |
2 participants
Add a
datasets/{identifiers}/tagsendpoint as a modern alternative to/data/tag.In case where we can easily already introduce a newer style API without much overhead in development, I think we probably should do so. This would be an example of that. I wouldn't go so far as to introduce changes with significant change in functionality (such as allow multiple tags at once) since those may require additional discussion (e.g., what happens is one of those multiple tags already exists?). In this case, only the response code and body is changed, but we don't generally expect people to use the response body anyway (it was likely included in the PHP API because it was "free" in their code path since they performed the duplication check in PHP instead of at the database, and so already had fetched all tags).