@ifried, do we need logging for this?
Fri, Jul 12
Ready for review: https://github.com/wikimedia/svgtranslate/pull/128
MariaDB [zerowiki]> show tables; +--------------------------+ | Tables_in_zerowiki | +--------------------------+ | abuse_filter | | abuse_filter_action | | abuse_filter_history | | abuse_filter_log | | actor | | archive | | babel | | betafeatures_user_counts | | bot_passwords | | bv2015_edits | | bv2017_edits | | category | | categorylinks | | change_tag | | change_tag_def | | comment | | content | | content_models | | cu_changes | | cu_log | | externallinks | | filearchive | | filejournal | | geo_tags | | global_block_whitelist | | globalblocks | | hidden | | image | | imagelinks | | interwiki | | ip_changes | | ipblocks | | ipblocks_restrictions | | iwlinks | | job | | l10n_cache | | langlinks | | linter | | log_search | | logging | | math | | mathoid | | module_deps | | oathauth_users | | objectcache | | oldimage | | page | | page_props | | page_restrictions | | pagelinks | | protected_titles | | querycache | | querycache_info | | querycachetwo | | recentchanges | | redirect | | revision | | revision_actor_temp | | revision_comment_temp | | searchindex | | securepoll_cookie_match | | securepoll_elections | | securepoll_entity | | securepoll_lists | | securepoll_msgs | | securepoll_options | | securepoll_properties | | securepoll_questions | | securepoll_strike | | securepoll_voters | | securepoll_votes | | site_identifiers | | site_stats | | sites | | slot_roles | | slots | | spoofuser | | templatelinks | | text | | transcache | | transcode | | updatelog | | uploadstash | | user | | user_former_groups | | user_groups | | user_newtalk | | user_properties | | watchlist | +--------------------------+ 89 rows in set (0.00 sec)
The main places where data we can't keep for more than 90 days is stored are cu_*, recentchanges and abuse_*. All these tables are already empty. Data in ip_changes is not private but only has 2 edits by localhost made during installation anyway:
MariaDB [zerowiki]> select * from ip_changes; +------------+-------------------+----------+ | ipc_rev_id | ipc_rev_timestamp | ipc_hex | +------------+-------------------+----------+ | 1 | 20140401184017 | 7F000001 | | 2 | 20140401184018 | 7F000001 | +------------+-------------------+----------+ 2 rows in set (0.00 sec)
Unless someone knows something else, I'd say it's safe to store a backup of this database for a long time.
Thu, Jul 11
Wed, Jul 10
I've set up a cronjob to restart the webservice at 3:30 UTC daily, let's see if it helps.
Tue, Jul 9
Because 2 minutes wasn't enough either, I've just disabled the timeout completely, emulating the previous behavior.
Mon, Jul 8
Thu, Jul 4
The timeout was implicitly added in https://github.com/wsexport/tool/commit/2f7f5a9598786975d26d74df6d6e2cf8168b413b
Wed, Jul 3
There is a setting for that, we're just not going to change it because it's intended to protect against page parsing being too slow. If your wiki is systematically exceeding this limit, the problem is with your wiki's templates, not the limit. I'd recommend you to reduce the templates and port some of them to Lua modules.
Tue, Jul 2
Can't tell because logs don't have timestamps, but the error log is pretty large.
Unfortunately, Argon2 will most likely be broken in a backwards-incompatible way in PHP 7.4: https://wiki.php.net/rfc/sodium.argon.hash
Mon, Jul 1
Ready for review.
Fri, Jun 28
They look fine to me :O
Ready for review: https://github.com/wikimedia/database-reports/pull/27
@dom_walden, please poke me next time it malfunctions, I'll try debugging it live. Moving it from the kanban board until then.
Wed, Jun 26
Due to BlockManager changes, this has generated 256 errors in the last 15 minutes. Needs fixed ASAP. Also, removing irrelevant tags not related to the actual problem. It's neither restricted to ru: and zh:, nor does it have TextExtracts in its stacktraces.
Ready for review.
Fri, Jun 21
Since the immediate issue has been resolved and nothing similar has popped up so far, guess we can close.
Wed, Jun 19
Tue, Jun 18
2.37 sec is not good at all. Look at the query plan:
The reason this was introduced is that some hashes contained ad which some adblocked blocked as... ads. Is this less of a concern these days?
Mon, Jun 17
Start with disabling uBlock and anything else that might prevent pages from executing fully.
Jun 16 2019
I would actually object to this: imagine your change has caused multiple test failures that you weren't able to predict in your dev environment (because you didn't have all extensions installed or your environment is otherwise different from our CI). You'll have to amend your PR with one fix at a time and push it just to see what explodes next.
Run CI browser tests in parallel
Jun 14 2019
has not been updated since 28th May. I thought it should have updated by now. I will keep an eye on it.
Jun 12 2019
Let's open a new ticket.
Jun 11 2019
Jun 10 2019
The Database Requests PR has been finally merged and deployed.
Jun 7 2019
What is the status of what WMDE started working on; did they run into notable challenges we should know about before stopping?