mirror of https://github.com/zulip/zulip.git
dd954749be
This may happen if there are multiple servers with the same UUID submitting data (e.g. if they were cloned after initial creation), or if there is one server, but `./manage.py clear_analytics_tables` was used to truncate the analytics tables. In the case of `clear_analytics_tables`, the data submitted likely has identical historical values with new remote `id` values; preserving the originally-submitted contemporaneous data is the best option. For the case of submissions from multiple servers, there is no completely sensible outcome, so the best we can do is detect the case and move on. Since we have a lock on the RemoteZulipServer, we know that no other inserts are happening, so counting before and after will return the true number of rows inserted (which `bulk_create` cannot do in the face of `ignore_conflicts`[^1]). We compare this to the expected number of new inserted rows to detect dropped duplicates. [^1]: See https://code.djangoproject.com/ticket/30138. |
||
|---|---|---|
| .. | ||
| actions | ||
| data_import | ||
| integration_fixtures/nagios | ||
| lib | ||
| management | ||
| migrations | ||
| openapi | ||
| tests | ||
| tornado | ||
| transaction_tests | ||
| views | ||
| webhooks | ||
| worker | ||
| __init__.py | ||
| apps.py | ||
| context_processors.py | ||
| decorator.py | ||
| filters.py | ||
| forms.py | ||
| logging_handlers.py | ||
| middleware.py | ||
| models.py | ||
| signals.py | ||