h/t @official-techsupport for digging into the regex performance and
coming up with one that greatly reduces backtracking. We see an
approximately 2x speedup under typical loads, which proves to be a
major overall savings in performance. Previously, censor_slurs was,
second to ORM DB accesses, by far the most time-consuming function
in the codebase under typical loads. It's still not ideal, but it is
much better.
Future options to improve this critical path further would be:
1) Precompute a slur-replaced HTML, rather than recomputing
each pageload. Storage is cheap.
2) Tokenize the HTML and replace plaintext words using O(1)
exact-match lookups to a dict.
The reddit mentions system contained much duplicated code and was
grafted onto the post thumbnail pipeline to achieve semi-regular
invocation. Instead, we now run it through the new cron system,
and the duplicate code has been refactored out.
Adding an empty __init__.py, the imports-only cli.py, and setting
FLASK_APP in the environment are enough to get the `flask` command
to work. This will enable future changes, including database
migrations.
The proximate reason for the fix is to add a `flask cron` command
to run scheduled tasks within the application from cron. Specifically,
the lottery should be run from cron.
Previously, the three instances of 'Report[s]' and one instance of
'Coin[s]' in the UI templates were always pluralized, even when they
referred to a singular instance. This has been corrected by creating
a `plural` helper macro.
Additionally, this was used as impetus to create `utils/helpers.html`
to eventually move more recurring template logic into macros.
This is a kludge solution that sticks special case logic in places
it shouldn't be. However, community management demands necessitate it
quickly. Of the three ways to change a flair (customtitle), this
prevents using flairlocks and admin flair editing on the user with
CARP_ID. Only the user himself may change his flair through settings.
It was observed in prod that the lottery prize as tracked by the DB
had diverged from the amount held in the Lottershe manager account.
This appears to be the result of grant_lottery_tickets_to_user
adding the # of _tickets_ rather than the value of those tickets to
the manager.
- Increment cache version on popover badges.
- Add comments+submission_listing.js to assetcache to support ^.
- Append new words to wordle list.
- Cache bust assorted assets for recent PRs.
In general, we don't do a great job of length validating body_html
fields. Lots of ways to get 500 errors by providing too long of
input. Really ought to find a way to fix it in the classes/comment.py
and classes/submission.py classes. In the interim, the recent gifts
messages change is salient because the notification can 500 out
mid-way through performing coin transactions.
Recommended to find a better way of truncating or safely bubbling
the exception up. Truncating probably not best long-term solution
because it could hypothetically permit strings that would otherwise
be considered unsanitized.
Assetcache: now supports js/userpage.js & js/userpage_v.js.
The three userpage*.html templates now implement it.
Revising gift messages 16587cdf7cf5:
- routes/users.py: Deduplicate code, more descriptive var name.
- templates/userpage.html: Move post-tax gift line below reasons
box. Ultimately just an aesthetic change.
Some users have complained about performance with the backdrop-filter
on .modal-backdrop.show. Partially as a kludge to avoid adding another
toggle, the 'animations' user setting now also disables the backdrop
filter. In practice, this may turn into a more general setting to
remove performance-intensive UI effects.
A rare case where users receive 0 lotto tickets from a treasure chest
occurs when they received 10 or 11 coins from a chest pre-conversion
to lotto tickets. Rather than change ticket_count to the ceil of
dividing coins by ticket cost, it seems less distortionary to instead
imperceptibly raise the minimum to avoid this case.