Great idea. Would be very helpful.

In T252226#6119429, @DannyS712 wrote:

Tagging DBA for feedback regarding whether its okay to be expanding the cu_changes table

See updated task definition. The additional rows may not be that many.

In T252226#6119436, @Huji wrote:

In T252226#6119429, @DannyS712 wrote:

Tagging DBA for feedback regarding whether its okay to be expanding the cu_changes table

See updated task definition. The additional rows may not be that many.

Not sure how large the table currently is, but adding 30,000 rows should probably be looked at by DBA first

In T252226#6119438, @DannyS712 wrote:

In T252226#6119436, @Huji wrote:

In T252226#6119429, @DannyS712 wrote:

Tagging DBA for feedback regarding whether its okay to be expanding the cu_changes table

See updated task definition. The additional rows may not be that many.

Not sure how large the table currently is, but adding 30,000 rows should probably be looked at by DBA first

I am not debating that; just indicating it may be an easy "yes" by DBA.

Also, note that it is not 30K additional rows, but rather 90K (because of retention policy of 3 months).

I am guessing enwiki has tens of millions of rows in cu_changes (given their 5 million edits per month + other logs). For wikidata it is probably in the order of hundreds of millions of rows (given their 20 million edits per month).

In T247540, Reedy indicated that the table has about 60,000,000 rows on wikidata and 10,000,000 on enwiki.

From what I can see these are the number of rows on cu_changes:
enwiki: 18305102
commons: 24673959
wikidata: 67864207

So the numbers you provided (ie: 30k, 2k) those are the extra rows per month + and then we have to apply a 3 months retention policy?
After those 3 months we'll clean up those rows?

In T252226#6143629, @Marostegui wrote:

From what I can see these are the number of rows on cu_changes:
enwiki: 18305102
commons: 24673959
wikidata: 67864207

So the numbers you provided (ie: 30k, 2k) those are the extra rows per month + and then we have to apply a 3 months retention policy?
After those 3 months we'll clean up those rows?

Yes, that is believed to be the db impact of such logging

So as long as we use the normal methods to delete stuff (small batches, wait for replication etc) I think we should be fine.
Considering the sizes of the tables, the % of additional rows (including the retention policy) is 0.5% on enwiki and 0.01% on wikidatawiki.

Let's please make sure the purging works as expected to avoid the table getting out of control.

Change 596998 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/Thanks@master] ApiThank: Send thanks logs to checkuser when extension is enabled

https://gerrit.wikimedia.org/r/596998

Change 596998 merged by jenkins-bot:
[mediawiki/extensions/Thanks@master] ApiThank: Send thanks logs to CheckUser when extension is enabled

https://gerrit.wikimedia.org/r/596998

In T252226#6143640, @Marostegui wrote:

So as long as we use the normal methods to delete stuff (small batches, wait for replication etc) I think we should be fine.
Considering the sizes of the tables, the % of additional rows (including the retention policy) is 0.5% on enwiki and 0.01% on wikidatawiki.

Let's please make sure the purging works as expected to avoid the table getting out of control.

Okay, the patch has merged. Should we leave this open for monitoring of the table size for the next 90 days?

Which wikis have it currently enabled?

In T252226#6280463, @Marostegui wrote:

Which wikis have it currently enabled?

All wikis with CU and thanks - there is no feature flag

I just used User:T255506 to thank myself on fawiki and then I ran a check on that user. The check returned no results for the past 7 days.

Looking at Special:Version on fawiki, Thanks is on 895bb0b99d1b940 which is the June 29th branch. The patch was merged on July 3rd so it has not reached the Wikipedias. Let's keep this open until we verify it worked on the Wikipedias. After that, I think we should close this but open a new task for monitoring DB size. We should define the definition of done for that new task. Are we going to monitor indefinitely? for a few weeks? months? Are we going to take specific actions if we notice the DB size is growing too fast (which is unlikely)? How often are we going to pull row counts from the DB? Are we going to look at total row count, or just count of rows from Thanks? They all need to be define in the new task. @DannyS712 do you want to create it?

In T252226#6281693, @Huji wrote:

I just used User:T255506 to thank myself on fawiki and then I ran a check on that user. The check returned no results for the past 7 days.

Looking at Special:Version on fawiki, Thanks is on 895bb0b99d1b940 which is the June 29th branch. The patch was merged on July 3rd so it has not reached the Wikipedias. Let's keep this open until we verify it worked on the Wikipedias. After that, I think we should close this but open a new task for monitoring DB size. We should define the definition of done for that new task. Are we going to monitor indefinitely? for a few weeks? months? Are we going to take specific actions if we notice the DB size is growing too fast (which is unlikely)? How often are we going to pull row counts from the DB? Are we going to look at total row count, or just count of rows from Thanks? They all need to be define in the new task. @DannyS712 do you want to create it?

I'll leave that decision to @Marostegui

I would like to see how much the tables grow per week on the biggest wikis (enwiki, commons, wikidata)...for around 1 month since it gets fully deployed. We can check those % from the backups.

@DannyS712 one more thought: should we do a User-notice for this change?

In T252226#6283196, @Huji wrote:

@DannyS712 one more thought: should we do a User-notice for this change?

Probably

I'm confused. Isn't Thanks public anyway? What will CheckUsers be able to see that they couldn't before?

In T252226#6299866, @JJMC89 wrote:

The Thanks log entries are public, but the UA and IP of the user are not being made available in CU like happens with other logs in MW core.

That makes more sense. Thanks!

In T252226#6299713, @BEANS-X2 wrote:

I'm confused. Isn't Thanks public anyway? What will CheckUsers be able to see that they couldn't before?

The Thanks log entries are public, but the UA and IP of the user are not being made available in CU like happens with other logs in MW core.

Also, the current thanks log only shows who thanked who. Why does it not list which edit/logaction was thanked for?

@Naleksuh that was never a public log. I think adding that feature requires approval not just by WMF teams (Legal and T&S) but also by the communities. I, for one, think that is not necessary information for CUs to know and would oppose it. As far as CU is concerned, just having the IP and UA associated with the Thank event should suffice.