Here are the baselines for wikis that has highest transclution of Cite Q module and causing unnecessary EU of item Q4233718

Heyy everyone, this reparse and compare solution seems very intuitive but I see two challenges:

• It wont fix it for pages has no cache, so the noise will remain for them in RC table.
• The current code flow is not waiting the page to be parsed, this solution requires a big refactor on client side.

Hey @Tacsipacsi , thanks a lot for the inputs. I will try to answer some points you mentioned. Lets keep challenge this suggestion so that we will implement the best one at the end.

Heyy, thanks for the suggestion. Yes, they will be reached pretty soon, we are on it.

French wiki has some high numbers accessing all statements: https://phabricator.wikimedia.org/P87630
This could be related with Lua investigation T403008 or this could be something else.

It seems like this data track can be found on Grafana, we need to look into it.

Some other things that we discussed in our recent brainstorming (everything is arbitrary and nothing is decided yet) to have them written somewhere:

• Having a time limit i.e. merging logs older than 20 days, removing language logs if they are older than 20 days.
• How to merge them? Options would be in repo before change propagation, after they reach to client, after they are in DB or even more crazy on repo when they are created.
• What to merge should be another thing to decide if we decide to merge. Some highlights were around logs at the same time, by same person, for the same operation, same statement edits etc. ----

As a separate topic, we all agreed filtering out option is nice to have for language added logs.

Hi, could you please provide more description for this task? Are we meaning Extension:WikimediaBadges? Could you please share the steps to test your changes as well?

I think we should at least think about an option to filter them out for users who wouldn't be interested with them. However, this doesn't improve anything on DB load issue.

We can investigate modules like databox or infobox and see if there's optimisations to reduce usage tracking. For example, if the module code touches any parts of the entity, regardless of whether it prints this info to the page, it will be registered as a usage. Maybe there is a way to simplify the code and therefore save on change propagation

This ticket can increase priority after we recognized that we need more reduce in DB. Here are latests brainstorm:

Happy to take a look at it further but after initial quick check, this actually could be the expected behavior.

• If there is no single filter, that might mean we see all changes. So it is normal to see Wikidata changes there as well.
• If there is at least one filter included (and Wikidata changes filter is not selected), you should not see Wikidata changes. This is the case in the wikis we tested included nl wiki.

Done :) Sorry for the delay I was sick off previous week.

Hi, sorry for the delay. I had a problem accessing Slack but now I managed to sent my public key to Amir. My public key is already written here on the ticket so I am not sure if I understand the task correctly. Could you elaborate more what I need to do for the process to continue @Dzahn ? If you need me sending my public key to you, which channel do you prefer?

Heyy, it might be related with 1194728, what do you think @Daimona and @cmelo ?

Thanks @dancy ! All of the exception traces are on version wmf.17. But we included these changes for wmf.18. Can you think of any reason that some systems were on previous version during the deployment? #

This issue is solved.

Thanks for doing that @Volker_E !:) Is there anything else that has to be done on our side? We need to have these icons for a patch to be deployed soon. I am happy to do anything remained to proceed this process so that our code change will be unblocked.