I will stand by, because I think I gave you all info you needed (which hopefully was useful). I will require the deletion of those files I generated after this is fixed; and of course you have my offering of anything that I could do to help.

If this is not causing any errors or problems, then I do not believe it is worth addressing at this time. @kaldari , thoughts?

In T178512#3694558, @TBolliger wrote:

If this is not causing any errors or problems, then I do not believe it is worth addressing at this time. @kaldari , thoughts?

It isn't, but it's possible/likely that those people previously had actual users on their blacklist in place of those zeroes, and that that data was lost. It may or may not be recoverable, but it would be good to make sure that such data loss does not continue.

In T178512#3694664, @Catrope wrote:

It isn't, but it's possible/likely that those people previously had actual users on their blacklist in place of those zeroes, and that that data was lost. It may or may not be recoverable, but it would be good to make sure that such data loss does not continue.

According to T178313, these people did not have actual users on their blacklist (unless the analysis by @jcrespo and myself is inaccurate).

SELECT count(*) FROM user_properties WHERE up_property = 'echo-notifications-blacklist' AND up_value REGEXP '^(0|0\n)+$'; currently returns 1671 on English Wikipedia. Let's keep an eye on that number and see if it changes.

Unless you are saying they had a valid list, and that list has been lost at some point in the last week? (and not specifically after deployment?)

In T178512#3694691, @kaldari wrote:

SELECT count(*) FROM user_properties WHERE up_property = 'echo-notifications-blacklist' AND up_value REGEXP '^(0|0\n)+$'; currently returns 1671 on English Wikipedia. Let's keep an eye on that number and see if it changes.

It has been steadily increasing every time I've checked it.

In T178512#3694691, @kaldari wrote:

SELECT count(*) FROM user_properties WHERE up_property = 'echo-notifications-blacklist' AND up_value REGEXP '^(0|0\n)+$'; currently returns 1671 on English Wikipedia. Let's keep an eye on that number and see if it changes.

That's more than when I first found the issue on Saturday. It was in the 1300s then.

Also, there are currently 11012 entries set to ''.

In T178512#3694801, @kaldari wrote:

It's 1674 now, so it's definitely increasing.

Yeah it's 1,754 now. How should this task be prioritized?

Let's get this into our Sprint 8 (Oct 25 - Nov 7) or Sprint 9 (Nov 8 - 21) following the Interaction Timeline MVP.

However, if we realize this is more time sensitive, we can bump to before the Timeline.

Since this might require a huge amount of debugging, we'll instead prevent zero's from being written, if the number stops increasing then we will have resolved the issue.

Current number of accounts with zeros on en.wiki: 2378.

@dmaza you were right about the intval

php > print_r(array_map( 'intval', explode( "\n", '') ));
Array
(
    [0] => 0
)
php > print_r(array_map( 'intval', explode( "\n", ' ') ));
Array
(
    [0] => 0
)
php > print_r(array_map( 'intval', explode( "\n", '0') ));
Array
(
    [0] => 0
)

So people who have an empty string (or just a space for that matter) are getting converted to 0.

Change 391032 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/extensions/Echo@master] Prevent loading or saving of zeros in the database.

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

Change 391032 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Prevent loading or saving of zeros in the database.

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