Is this functionality blocked on something else?

Even if I'd provide the diff?

--no-index - diff is created outside of repository by comparing directories.
--no-prefix - I'm not sure about this - some historical reasons and code in the service which generates diffs. But as I understand this was supported since D3744 and until rARCd0957c344156356123048be2219fb95a54c89a85.

@epriestley git diff --no-index --no-prefix -U2000 $old_file_path $new_file_path

I see your point with different "open" statuses.

@chad False alarm, I've checked wrong link. Problem existed on Maniphest global rules but it seems it is fixed already on upstream.

Thanks for explanation!

@chad ^^

Currently we have over 1500 active herald rules. Over 1000 of them are global.

Yeah. Sorry, was using version prior mentioned diff. Thanks!

Can you suggest the best way to achieve this?

My previous DELETE queries just reduced amount of tasks created, but I'm still getting few of those tasks.

Thank you for full explanation.

@epriestley any thoughts? This issue is blocking entire queue.

Execution log: P1855

Thanks for info!

Usually we are restarting builds on Jenkins if they failed due some environment issue. For example connection problems or git misconfiguration. If other words if build failed not because of code changes in diff, we restart build on Jenkins.

This was false alarm. key_chronological index was not added on feed_storynotification table on production db (but was added on local). I'm sorry for wasting your time :-)

I doubt it is Percona issue. I've just tried perform same queries on my laptop with MySQL 5.6 and small data set. Still getting the same results as above.

Getting the same as above still.

Same

mysql> EXPLAIN SELECT * FROM feed_storynotification WHERE chronologicalKey < 6175228766710272490 ORDER BY chronologicalKey DESC LIMIT 100;
+----+-------------+------------------------+-------+---------------+------------+---------+------+---------+------------------------------------------+
| id | select_type | table                  | type  | possible_keys | key        | key_len | ref  | rows    | Extra                                    |
+----+-------------+------------------------+-------+---------------+------------+---------+------+---------+------------------------------------------+
|  1 | SIMPLE      | feed_storynotification | index | NULL          | userPHID_2 | 133     | NULL | 2941950 | Using where; Using index; Using filesort |
+----+-------------+------------------------+-------+---------------+------------+---------+------+---------+------------------------------------------+
1 row in set (0.00 sec)

I'm getting different results:

Yes, I've solved this way. chronologicalKey already existed on the table but we had over 13 million records there. And performing DELETE query took quite long. Apparently it locked inserts to feed_storynotification table what caused deadlocks.

My previous Phabricator version was early 2015-May. I see, a bit later FeedStoryNotificationGarbageCollector was introduced (D13233).

I see your point and sounds fair for me.

We are providing different tokens for each URL.
And this parameter is not stored on Phabricator :-(

Each rule has different parameters in steps. In our case it is different HTTP Request URL.

We trying to automate Harbormaster + Herald setup for new repositories in our company (have plans to provide Harbormaster API methods soon). This method is required to check if specific rules are not created yet.

Took almost 6 hours to apply all adjustment patches (our database is quite huge).
Some patches failed with Row size too large (> 8126) MySQL error. Increasing innodb_log_file_size parameter to 1G helped.
Then failed on phabricator_conduit.conduit_methodcalllog.method with #1406: Data too long for column 'method' at row ... message. Since it is log table, truncating all data solved the issue.