Django lazy-loads much of its modules, including the application's.
This defers the time to during the first request it serves. When
doing rolling-restarts, this means that the worker is marked "ready"
despite having multiple seconds more work to do. With small numbers
of workers, this causes a significant capacity drop, since effectively
more than one worker can be still reloading at a time. It also
results in poor user experience for the requests which are unlucky
enough to be served first.
Use the technique detailed in the uwsgi documentation[^1] to fake a
request during initial application load, which forces the application
to be loaded.
[^1]: https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#dealing-with-ultra-lazy-apps-like-django
This has the impact of making rebuilding the database in a Zulip
development environment, or initializing a new production database,
dramatically faster.
This was generated by merging the output of `manage.py makemigrations`
with an empty migration.
Tested using `tools/rebuild-test-database` before and after this
change, and comparing the output of `pg_dump -d zulip_test` using
Git's diff comparison algorithm. Differences in that SQL dump include:
- The actual generated table contents, due to timestamps and the like;
this is expected and unrelated to schema.
- Orders of fields within tables, which is not significant in SQL.
- IDs assigned to tables in the ContentType table, which is expected
and not a problem with how that Django table is designed.
- Names of generated indexes and constraints; modern Django seems to
abbreviate long names differently for these, and it's not obviously
possible to configure those used by the `db_index` property. If
necessarily, likely this can be converged via a migration filled
with `IF EXISTS` rename operations like the one done in
zerver/migrations/0246_message_date_sent_finalize_part2.py.
- Names of the ~3 sequences related to renamed tables:
usertopic/mutedtopic, botconfigdata/botuserconfigdata,
realmdomain/realmalias. Probably there's no action required here,
but we could do rename operations if desired.
Generated using manage.py squashmigrations, with minimal manual
surgery to replace the original migration.
This should in theory produce the exact same database state as
previously.
This has no functional changes, but it helps the squashmigrations tool
realize some squashing opportunities to not have models declared
before other models that they will gain a foreign key to.
Generated using manage.py squashmigrations, with some work:
- Used my patch to support squashing AddConstraint/RemoveConstraint
operations.
- Manually removed the add/deletion of cloud_xor_self_hosted, since it
didn't squash properly.
- Temporarily removed a couple operations from their migration files,
and added them back manually both to the original file and the
squash file, to allow later operations to squash
properly. Specifically, these are the two unsquashed operations
documented with comments at the end of the squash migration file.
Created using manage.py squashmigrations, with my patch to the Django
migration optimizer to correctly collapse
AddConstraints/RemoveConstraints operations.
Created using manage.py squashmigrations with a couple changes:
- Patched Django to optimize AddConstraints/RemoveConstraints properly.
- Used the StateOperations from the
migrations.SeparateDatabaseAndState section in migration 0060, so
that the constraint changes could be optimized properly.
- Removed dependencies on zerver, since this project does not actually
have any dependencies on zerver migrations.
Generated using the squashmigrations tool, with:
- A tiny Django patch to avoid special handling of the temporary
EmailChangeStatus proxy model.
- Switching AddIndexConcurrently to AddIndex to help squashing. This
may not have been necessary.
Migration 0015 was not squashed because of its dependency on newer
zerver migrations.
Since it's the initial migration, this can't have any useful effect.
I'm pretty sure the backstory is we did a manual squash of migrations
during the process of open-sourcing Zulip, and incorrectly didn't
remove this code.
It's not possible to directly upgrade from pre-5.3 versions to main,
since they do not have any supported OSes in common. Thus, this
dependency on the confirmation model, which risks creating a circular
dependency if we squash migrations, can be removed.
Adds some validation for changing the realm's max invites via the
support view so that it is not set below the default max for the
realm's plan type, and so that if it's currently set to the default
max it's not reset to that same value.
This commit adds '*' as a keyboard shortcut to navigate to the starred messages view and the shortcut is documented in various required locations accordingly.
Fixes#31397.
The 10.0-dev tag was created on the wrong commit, and force-pushing
it would break upgrade-zulip-from-git. Merge it into main so that
cache-zulip-git-version detects the right version.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This commit adds a new `group_size` field to the `DirectMessageGroup`
model, and backfills its value to each of the existing direct message
groups.
Fixes part of #25713
It is better to have stream dropdown option value, which is the ID
of the stream, to be of "number" type.
This fixes the assertion error which occurred when someone tried to
subscribe the user to a stream from user profile modal.
Earlier, we were using 'send_event' in 'do_change_is_billing_admin'
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in
'do_update_outgoing_webhook_service' which can lead to a
situation, if any db operation is added after the 'send_event'
in future, where we enqueue events but the action function fails
at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in
'do_set_push_notifications_enabled_end_timestamp' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_set_realm_stream' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in
'do_set_realm_authentication_methods' which can lead to a situation
where we enqueue events but there's an error at a later stage in
the codepath using this function.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in do_set_realm_user_default_setting
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_regenerate_api_key'
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Anders Kaseorg
Alex Vandiver
Tim Abbott
Lauryn Menard
opmkumar
Aman Agrawal
Anders Kaseorg
afeefuddin
Varun Singh
roanster007
Alya Abbott
Sahil Batra
Shubham Padia
Prakhar Pratyush