-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Closes 20817 fix datasource sync broken when cron is set #20837
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 9 commits
b4160ad
111aca1
bfeba36
2e0ff04
a49869a
5b5b5c8
e11508d
71f707b
da4c669
57b47dc
3016b1d
e4b6140
929d024
93e5f91
09d1049
77ee6ba
544c97d
cf16a29
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -13,13 +13,15 @@ class DataSourceStatusChoices(ChoiceSet): | |||||
| SYNCING = 'syncing' | ||||||
| COMPLETED = 'completed' | ||||||
| FAILED = 'failed' | ||||||
| READY = 'ready' | ||||||
|
|
||||||
| CHOICES = ( | ||||||
| (NEW, _('New'), 'blue'), | ||||||
| (QUEUED, _('Queued'), 'orange'), | ||||||
| (SYNCING, _('Syncing'), 'cyan'), | ||||||
| (COMPLETED, _('Completed'), 'green'), | ||||||
| (FAILED, _('Failed'), 'red'), | ||||||
| (READY, _('Ready'), 'green'), | ||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You say SCHEDULED status is added but there is no scheduled in the status or code anywhere? Still confused as you state "The two new states are READY & SCHEDULED."
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I ended up removing it, so there is only one state that has been added in the end, which is the The reasoning behind was that
|
||||||
| (READY, _('Ready'), 'green'), | |
| (READY, _('Ready'), 'gray'), |
| Original file line number | Diff line number | Diff line change | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -16,6 +16,7 @@ | |||||||||||||||||
| from utilities.forms.fields import CommentField, JSONField | ||||||||||||||||||
| from utilities.forms.rendering import FieldSet | ||||||||||||||||||
| from utilities.forms.widgets import HTMXSelect | ||||||||||||||||||
| from core.choices import DataSourceStatusChoices | ||||||||||||||||||
|
|
||||||||||||||||||
| __all__ = ( | ||||||||||||||||||
| 'ConfigRevisionForm', | ||||||||||||||||||
|
|
@@ -79,14 +80,24 @@ def __init__(self, *args, **kwargs): | |||||||||||||||||
| if self.instance and self.instance.parameters: | ||||||||||||||||||
| self.fields[field_name].initial = self.instance.parameters.get(name) | ||||||||||||||||||
|
|
||||||||||||||||||
| def save(self, *args, **kwargs): | ||||||||||||||||||
| def clean(self): | ||||||||||||||||||
| super().clean() | ||||||||||||||||||
| if not self.instance.pk: | ||||||||||||||||||
| self.cleaned_data['status'] = DataSourceStatusChoices.NEW | ||||||||||||||||||
ifoughal marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||||||||||
| else: | ||||||||||||||||||
| if not self.data.get('sync_interval'): | ||||||||||||||||||
ifoughal marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||||||||||
| if not self.data.get('sync_interval'): | |
| if not self.cleaned_data.get('sync_interval'): |
Outdated
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This condition will always be False for updates because self.instance.pk will exist for existing instances. The logic appears to be checking if this is a new object, but the code only sets status to NEW when the instance doesn't have a pk. However, for creates, Django forms with ModelForm already have self.instance set with a pk=None before save. After clean() is called but before save(), the instance won't have a pk yet, so this condition should use self.instance.pk is None or check the _state.adding attribute. But more critically, this logic shouldn't override the status for updates when the DataSource already has a valid status from a sync operation (COMPLETED, FAILED, etc.).
| if not self.instance.pk: | |
| self.cleaned_data['status'] = DataSourceStatusChoices.NEW | |
| else: | |
| if not self.data.get('sync_interval'): | |
| self.cleaned_data['status'] = DataSourceStatusChoices.READY | |
| # Only set status to NEW if this is a new instance | |
| if self.instance.pk is None: | |
| self.cleaned_data['status'] = DataSourceStatusChoices.NEW |
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic for setting status based on sync_interval is incomplete. According to the PR description, when a user sets a sync interval, the status should be set to "Scheduled". However, this code only handles the case when sync_interval is removed (setting to READY), but doesn't set the status to SCHEDULED when sync_interval is present. There's also no SCHEDULED state defined, so you should add an else branch to handle when sync_interval is set (e.g., set status to QUEUED or implement SCHEDULED).
| else: | |
| self.cleaned_data['status'] = DataSourceStatusChoices.QUEUED |
Outdated
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic unconditionally overwrites the DataSource status from the form's cleaned_data. This will break the intended behavior where sync operations set the status to SYNCING, COMPLETED, or FAILED (as seen in DataSource.sync() method and SyncDataSourceJob). After a sync completes and sets status to COMPLETED or FAILED, if a user edits the DataSource, this form will reset the status to READY or NEW, losing the sync result information. The form should only update the status when explicitly changing sync_interval settings, not on every save.
Outdated
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The status modification in clean() will interfere with the enqueue_sync_job signal handler in signals.py (line 259-275). When saving a DataSource with a sync_interval, the sequence will be: 1) Form sets status to READY (or NEW), 2) Form saves the instance, 3) The post_save signal fires and enqueues a job, 4) The SyncDataSourceJob.enqueue() sets status to QUEUED. This creates an inconsistent state where the form's status is immediately overwritten. The form should not manage status at all, or should coordinate with the signal/job system.
Outdated
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The DataSource.status field is marked as editable=False in the model (data.py line 56), indicating it's intended to be managed programmatically, not by user input. Having the form manipulate this field directly violates this design principle. The status should be managed exclusively by the sync process (DataSource.sync(), SyncDataSourceJob) and the signal handlers, not by the form. This creates a conflict between the intended API design and the form implementation.
Outdated
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new status transition logic in the form's clean() and save() methods lacks test coverage. Tests should be added to verify that: 1) New DataSources get status=NEW, 2) Updating an existing DataSource with sync_interval removed sets status=READY, 3) Updating an existing DataSource with sync_interval set behaves correctly, and 4) Status from completed sync operations (COMPLETED/FAILED) is preserved appropriately. Consider adding tests to verify this form behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR description mentions introducing two new states: "Ready" and "Scheduled". However, only the READY state is added here. The SCHEDULED state is missing from the DataSourceStatusChoices. This means the logic described in the PR description for setting status to "Scheduled" when a user sets a sync interval cannot be implemented.