4af00f61a8 claimed that `on_finish` and
`on_connection_close` were mutually exclusive. In cases where a
`DELETE` is called on the queue while a longpoll is in progress, this
can cause _both_ to happen:
- The `DELETE` pushes a `cleanup_queue` event, which triggers
`finish_handler` to begin pushing out an empty event response to the
longpoll connection.
- In the midst of that, in an `await`, the longpoll connection drops,
and `on_connection_close` clears the handler.
- The `await` resumes, calls `finish`, and attempts to clear the
handler.
The easiest solution is to make `clear_handler_by_id` tolerant to
multiple attempts to clear it. Since these processes run in parallel,
it means that parts may have a `handler_id` but `get_handler_by_id`
may error in attempting to look it up. We have not observed this in
testing, and I cannot currently prove it is impossible.
This ensures determinism in these tests doing mock_send.assert_called
with - avoids producing test flakes due to a different order of
retrieval of these objects from the database.
- The server sends the list of registrations it believes to have with
the bouncer.
- The bouncer includes in the response the registrations that it doesn't
actually have and therefore the server should delete.
This commit creates a RealmAuditlog entry with a new event_type
'RealmAuditLog.REALM_IMPORTED' after the realm is reactivated.
It contains user count data (using realm_user_count_by_role)
stored in extra_data.
This helps to have an accurate user count data for the billing
system if someone tries to signup just after doing an import.
This partially reverts 579bdc18f85ea8599c8cf1f53ddb02fd41d97993; it
assumed (based on its documentation) that `on_finish` was called for
all requests, even client-terminated ones. This is not accurate; it
is only called when the request calls `finish`, which only happens for
successful requests. This caused every client-closed connection to
leak a handler (ironically, exactly re-introducing the bug previously
fixed in 12a5a3a6e1).
This behaviour was obscured by the development environment's proxy;
see comment added in the previous commit.
Instead of replacing the `clear_handler_by_id` call into
`ClientDescriptor.disconnect_handler`, we instead place it on
`AsyncDjangoHandler.on_connection_close`. This is more correct for
a few reasons:
- `on_connection_close` will be called if the client goes away during
a request without a client descriptor. If the handler garbage
collection of handlers runs inside the ClientDescriptor, we leak
handlers.
- `disconnect_handler` also runs when successfully sending an event,
which already calls `on_finish`. We avoid double-calling
`clear_handler_by_id` by doing it in two clearly exclusive cases,
`on_finish` and `on_connection_close`.
- It combines the creation and garbage collection logic into one
file, decreasing action at a distance which causes memory leaks.
We call 'send_server_data_to_push_bouncer' just after registering
server for push notification.
This helps to have a current state of the user counts when first
logging in after the RemoteRealm flow.
Actions that change the number of user counts adds a deferred_work
queue processor job immediately update the billing service about your
change.
This helps to avoid having users see stale state for how many
users they have when trying to pay.
This is a rename of the previous
enqueue_register_realm_with_push_bouncer_if_needed but is clearer
about the fact that this will also upload audit logs if available.
Given that most of the use cases for realms-only code path would
really like to upload audit logs too, and the others would likely
produce a better user experience if they upoaded audit logs, we
should just have a single main code path here i.e.
'send_analytics_to_push_bouncer'.
We still only upload usage statistics according to documented
option, and only from the analytics cron job.
The error handling takes place in 'send_analytics_to_push_bouncer'
itself.
This is the only operating editing audit logs not already using a
transaction, and having it do so will simplify an upcoming interface
to be able to assume it is always inside a transaction.
Earlier, it was passing tests because the deffered_work queue
that calls send_realms_only_to_push_bouncer didn't update the
realms propery based on response received from bouncer.
This prep commit removes the invalid "dummy-uuid" used, as any
call to send_realms_only_to_push_bouncer will update realms
properties too.
We return an empty realms array as the realm is created midway in
do_create_realm, so the uuid is not already available. Also, our
intent here is not to verify the behaviour of the
send_realms_only_to_push_bouncer function because we'll have
separate tests for that. Here, we verify that deffered_work event
was sent and eventually it made call to send_to_push_bouncer
with appropriate data.
I accidentally free trials for both cloud and self hosted
enabled while testing, hence didn't catch it.
This mostly involves fixing `is_free_trial_offer_enabled` to
return the correct value and providing it the correct input.
The paragraph tag was being used along with the bold tag to style the
topic and stream in the popovers. The semantic meaning of these tags
are more specialized and should not be used in this context. Replaced
the <p> tags with the more general <div> tags and accounted for the
bold text via the `font-weight` CSS property.
The `.topic-name` class, used to style the topic/stream name in the
topic list in the left sidebar, was also being used to the style the
topic/stream name in the topic/stream popover. This lead to irrelevant
properties being applied to the popover > topic/stream name. Through
this commit, the styling for both of these different cases are now
separated using the appropriate selectors.
Fixes#27562.
When a stream name becomes very long, it may stretch the popover menu
by a lot. We prevent this by allowing the stream name to wrap onto
multiple lines.
We set the streams popover width to be equal to the width of the longest
menu item, via the min-content intrinsic sizing. We also set all the
menu items to `white-space: nowrap` to prevent them wrapping. These
two changes allow the menu items to dictate the width of the popover
instead of a static max-width property, and thus helps with languages
where the length of the translated item may be long enough to wrap.
We set the topics popover width to be equal to the width of the longest
menu item, via the min-content intrinsic sizing. We also set all the
menu items to `white-space: nowrap` to prevent them wrapping. These
two changes allow the menu items to dictate the width of the popover
instead of a static max-width property, and thus helps with languages
where the length of the translated item may be long enough to wrap.
It’s still used indirectly via Scrapy, but we haven’t used it directly
since commit 09e17fbe17 (#2002).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
As per the intended design, the font size of the org plan should
be equal to the font size of other similar links such as org version.
It should not be one size smaller than it, such as those of the
upgrade links.
Some organizations may have long names that could blow up the gear
menu width, in those cases we want to prevent it by wrapping the
org name by explicitly setting the white-space property, and thus
enabling any soft-wrap opportunities.
Through this commit, we set the width of the navbar dropdowns to be
equal to the longest menu item, via the min-content intrinsic sizing.
Note, that the min-content width takes into account all soft-wrapping
opportunities, which could result in the wrapping of the menu items in
many cases. To prevent this, we use the white-space property to prevent
menu items from wrapping in any case.
We currently don't have appropriate padding applied to the lists and
links in the org info section of the gear menu popover. This becomes
an issue when we have a long org name, org url or org version, as
text starts touching the edges of the popover.
This commit adds the missing padding to the items in the org info
section of the gear menu popover.
Pulls the forms for updating the billing collection method and
generally modifying the current plan to a separate template.
Uses the shared template to render these forms for both the
remote server and any attached remote realms.