chore: create unique constraints for webhook #6257
Conversation
WalkthroughThis pull request introduces modifications to the webhook and page log models in the Django application. The changes primarily focus on enhancing database constraints and serializer configurations. The updates include adding a Changes
Possibly related PRs
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
apiserver/plane/db/migrations/0088_alter_pagelog_entity_name_and_more.py (1)
22-29: Conditional Uniqueness Constraint
The “webhook_url_unique_url_when_deleted_at_null” constraint elegantly guards against duplication for active webhooks. However, watch out for potential race conditions in high-concurrency environments if multiple concurrent creations happen with the same URL. Consider adding a robust conflict-handling mechanism at the application level.apiserver/plane/db/models/webhook.py (1)
50-50: Explicitly Document Soft-Deletion Behaviour
The expanded unique_together with “deleted_at” indicates a soft-deletion strategy. Consider documenting these semantics in model docstrings or inline comments for clarity to future maintainers.apiserver/plane/db/models/page.py (1)
93-93: Flexible “entity_name” Field
Removing choices from “entity_name” fosters quick adaptability for new transaction types. However, ensure you have validations or enumerations in place if certain values must remain restricted.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
apiserver/plane/app/serializers/webhook.py(1 hunks)apiserver/plane/db/migrations/0088_alter_pagelog_entity_name_and_more.py(1 hunks)apiserver/plane/db/models/page.py(1 hunks)apiserver/plane/db/models/webhook.py(1 hunks)
🔇 Additional comments (4)
apiserver/plane/db/migrations/0088_alter_pagelog_entity_name_and_more.py (2)
18-21: Unique Together Constraint Addition
Including “deleted_at” in the unique_together for “webhook” helps side-step collisions with soft-deleted entries. This is a solid approach to gracefully handle duplicates when bringing the same URL back.
13-17: Ensure Removed Choices Are Fully Deprecated
Altering the “entity_name” field to remove choices can introduce flexibility in the model and migrations, but please confirm all references validating those choices are removed throughout the codebase to avoid unexpected errors.
✅ Verification successful
Let me check if the TYPE_CHOICES found in the search are actually related to the entity_name field in PageLog model.
Let me try a different approach to find the PageLog model definition and its usage.
Based on the search results, I can now provide a conclusive response:
Migration is Safe - No Impact on Type Validation
The TYPE_CHOICES found in the codebase are from different models (Page and DeployBoard) and not from the PageLog model. The entity_name field in PageLog is only used as a reference in one place (apiserver/plane/app/views/page/base.py) to filter issues, and it doesn't rely on choices validation. The migration to remove choices is safe as there are no explicit validations against a fixed set of choices in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that references to TYPE_CHOICES for entity_name are removed elsewhere
rg "TYPE_CHOICES" -A 5
Length of output: 804
Script:
#!/bin/bash
# Check PageLog model definition and any references to entity_name
ast-grep --pattern 'class PageLog {
$$$
}'
# Also search for any direct references to PageLog.entity_name
rg "PageLog.*entity_name" -A 3
Length of output: 79
Script:
#!/bin/bash
# Search for PageLog model definition with more context
rg "class PageLog" -A 10
# Search for any imports or references to PageLog
rg "PageLog" -A 2
Length of output: 11323
apiserver/plane/db/models/webhook.py (1)
55-61: Verify Database-Level Enforcement
The newly added UniqueConstraint effectively enforces uniqueness only for non-deleted entries. Ensure your application gracefully handles potential IntegrityError exceptions in case of race conditions or direct DB writes.
✅ Verification successful
Based on the search results, I can see that IntegrityError handling for webhooks is properly implemented in apiserver/plane/app/views/webhook/base.py. The code specifically handles the case where a URL already exists for the workspace and returns a proper HTTP 410 GONE response with an error message.
Webhook Uniqueness Constraint is Properly Handled
The application already handles potential IntegrityError exceptions for webhook creation with appropriate error responses. The implementation in apiserver/plane/app/views/webhook/base.py gracefully manages duplicate URL cases with proper error messaging.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Attempt to detect references to IntegrityError handling for Webhook creation
rg "IntegrityError" -A 5
Length of output: 13599
apiserver/plane/app/serializers/webhook.py (1)
119-119: Read-Only Field for Deleted State
Adding “deleted_at” to read_only_fields in the serializer is consistent with the new constraints and ensures that the soft-deletion timestamp cannot be inadvertently mutated. Great job maintaining data integrity.
Description
This pull request allows users to create a webhook with the same name, even if it has been deleted.
Type of Change
Summary by CodeRabbit
New Features
deleted_atas a read-only field in the webhook serialization.entity_namefield in thePageLogmodel.Bug Fixes
Documentation