Is this same as T231439: AssertionError [ERR_ASSERTION] in "App can edit a single string mainsnak value"?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 28 2019
Thanks!
In T224429#5443344, @Esanders wrote:With a well defined format, we could probably write an eslint rule for this.
I was testing this and noticed one significant issue when running rebuildLocalisationCache.php:
- With files (aka CDB) memory use stays <100M for each thread when running with 4 threads.
- With array memory use grows >500M for each thread when running with 4 threads.
Aug 27 2019
We're still on PHP 7.1. TwnMainPage doesn't have much dependencies, so extension-quibble-composer-nohhvm seems good and appropriate to me.
Would like review of the current patches before either I or someone else dig deeper how to resolve the known issue.
It seems extension-quibble should be replaced with either extension-quibble-composer-nohhvm or extension-quibble-php72-plus. I am not fully sure what are the differences. Former seems better, but what exactly does the composer part in it mean?
This looks quite simple replacement thing.
Maybe render to html and strip tags as a starters? The links are not so important imho.
I'm a bit confused here: Parser::getTitle() has for a long time been able to return null
Tentatively aiming for MLEB 2020.04
Aug 26 2019
For comparison, this is the query with SCHEMA_COMPAT_READ_OLD:
(Not related or affecting translatewiki.net at the moment).
I'm planning to leave this task unattended unless one of the following happens:
- The change is properly announced as a breaking change
- Someone does the work in Translate by submitting a patch in Gerrit
- This is fixed in the code who creates Parser without a Title
- This is fixed in Parser to not give out null titles
- Someone convinces me I should fix this anyway in Translate.
Parser::getTitle() is documented to return Title|null
Parser::getTitle() is documented to return Title|null, and the full file is sprinkled with is_null checks (but majority of cases assume mTitle is not null. I'd say the parser should be updated to require a valid title without everything having to check whether it has one or not.
It looks resolved to me. @Tacsipacsi can you confirm?
I think best would be to require annotating all dynamic message uses (near the place where they are used) with a specially formatted comment. We may need to support patterns like logentry-*-* unless we are okay having these comments somewhere else than near the wfMessage call.
There seems to be some edge cases still, outside the scope of this report. For example, focusing a section with missing block template.
Latest MLEB also requires PHP7 now.
Does not revert cleanly. Only workaround seems to be to roll back to commit before it.
Git bisect points to rMWe4468a1d6b6b: Make LocalisationCache a service. Setting UBN! for attention. I feel this doesn't affect everyone, though, or it would have been noticed already.
Aug 25 2019
This is ready to be implemented now.
There is nothing specific to test. This could basically affect any functionality. Example of regression this caused and which was fixed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/529809
Aug 24 2019
Thanks @Jdforrester-WMF!
Is there anything that justifies the additional complexity that is likely required to avoid reading it twice?
That page uses action=edit API module. Translate itself does not check for such permissions. Can you edit the page directly by clicking the title dropdown and choosing Show in wikieditor?
Aug 23 2019
Is the unit right? 150ms sounds very little, should it be seconds instead?
Aug 22 2019
Seems resolved. I'll reopen in case the warning does pop up again later.
Aug 21 2019
This error can only happen when $wgAdaptiveMessageCache = true;:
This has been deployed to translatewiki.net.
Does anyone have a script or anything that would quickly tell which paths have (non-obsolete) patches against them?
Aug 20 2019
I'll try dropping my local suppression for this tomorrow when updating code.
Great❣ Thanks for looking into this and fixing it.
Coming from the same line: PHP Warning: Invalid argument supplied for foreach()
Possibly not related at all, but want to mention T208897: PHP Fatal Error: Argument passed to MessageCache::isMainCacheable() must be array as a similar issue.
https://translatewiki.net/w/i.php?title=Special:MessageGroupStats&language=fi&group=phabricator#sortable:3=desc Hungary is available in Phabricator settings, but many languages above it are not.
Is it checking those 500 strings in some specific module? If so, I would like to document this on the project page.
Aug 17 2019
This bug and T217380: TranslateRenderJob: Cannot render translation page for Wikimania/pa-guru! are closely related, possibly even duplicates.
This looks like to be the case of using confusing error code, but no issue in functionality.
My guess is that this is either disk IO issue and/or related to recalculating message group stats. Let's see when we have the additional debugging available.
Aug 16 2019
Not sure, would require some more investigation to figure out what is setting mOptions to null (or not initializing it).
Aug 15 2019
Should be Thursday instead of Wednesday, right?