My expectation is that no upstream code exists to ever delete saved queries. My guess is that either:

• some such code actually does exist and I just missed it in reviewing PHI668; or
• the issue is actually with persisting the query in the first place, not deleting it?

I'm not sure what's caused this either but I've seen it twice on wikimedia's production install.

The downstream task is https://phabricator.wikimedia.org/T199207

Could it be that a user assigns it to one of their "personal" custom queries and then later they delete that query by way of the maniphest saved query ui?

In T13208#241647, @epriestley wrote:

[..] the issue is actually with persisting the query in the first place, not deleting it?

From the Wikimedia use case it seems to be that the query is created and saved from the workboard interface, and then while being constantly available for multiple users for multiple days, eventually it changes and everyone gets a 404.

I haven't been able to correlate it to a specific user action, it's possible that a user action does trigger it. But from an observer's perspective, it thus-far appears like the query is somehow expiring or getting garbage-collected, by itself.

There should be no code anywhere in Phabricator to delete saved queries. The expectation is that they are never deleted or garbage collected because they may have been embedded in other pages, sent via email, etc., and deleting a saved query will break any use of the link in a permanent/external context. The table is expected to grow without bound, although at a slow enough rate that it does not create a maintainability issue.

There is no garbage collector which deletes saved queries, and they should not be deleted when a named query is deleted. Nothing should ever delete them because deleting them definitely breaks a lot of stuff, not just Workboards.

The table itself will have discontinuities (i.e., not every id exists) but this is because INSERT bumps the AUTO_INCREMENT value when it fails with a duplicate key error.

On this install, the oldest SavedQuery is about 5 years old, suggesting that there is at least no TTL-based GC that I wrote while hopped up on goofballs and then simply forgot about:

mysql> SELECT FROM_UNIXTIME(MIN(dateCreated)) FROM search_savedquery;
+---------------------------------+
| FROM_UNIXTIME(MIN(dateCreated)) |
+---------------------------------+
| 2013-05-07 21:57:00             |
+---------------------------------+
1 row in set (0.07 sec)

It seems to be a fairly recent problem so there must be some code change that started triggering it. The worst part, IMO, is that the workboard breaks in a not-entirely-obvious way instead of falling back to a default query. It took me a while to debug the issue the first time it occurred.

Are there any workaround for this issue ?

@dlgiang: T13208#241682 above links to https://phabricator.wikimedia.org/T199207#4413718 describing a workaround

In T13208#242106, @aklapper wrote:

@dlgiang: T13208#241682 above links to https://phabricator.wikimedia.org/T199207#4413718 describing a workaround

@aklapper Thank you. But it does not work in my case. It is still 404. Maybe the code "query/cXWUBtEYlPCo/ " does not work for my case. Where can i find the this similar id ?

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

In T13208#242133, @20after4 wrote:

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

@20after4 Thank you very much. It works now

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.
Workaround: add "/query/all" at the end of the url also work fine.
I am still reviewing the database to to set back to the buitin query

I just a way to fix this. After using "/query/all" to get in the board. We can click on the "All Tasks" Filter -> "Save as Default" and we don't get issue 404 anymore.

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

These reproduction steps don't work for me, and don't make sense given how the software works. If you believe you have a set of reproduction steps, can you walk through them step-by-step in more detail so I can reproduce the issue?

If anyone can come up with reproduction steps which actually work, this will probably take me about 3 minutes to fix. The only thing blocking this is that I have no idea how to reproduce it.

In T13208#242142, @epriestley wrote:

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

These reproduction steps don't work for me, and don't make sense given how the software works. If you believe you have a set of reproduction steps, can you walk through them step-by-step in more detail so I can reproduce the issue?

If anyone can come up with reproduction steps which actually work, this will probably take me about 3 minutes to fix. The only thing blocking this is that I have no idea how to reproduce it.

The steps I provided on Discourse reproduce for me (I just tried again). Should I attempt to reproduce on this install?

I just tested and indeed @joshuaspence's steps are reproducible on https://phabricator.wikimedia.org

(I've added steps to reproduce to the task description)

Sorry! That reproduces cleanly for me too. I must have made a mistake following the reproduction steps or overlooked something. D19768 should fix this.

The root cause was that this:

$new_query = clone $old_query;
$new_query->save();

...replaces a query by causing us to UPDATE ... SET ... WHERE id = ... if $old_query is a saved (custom, user-provided) query. This is a weird interaction and doesn't happen when $old_query is a builtin query.

We can't get the old queries back, but D19768 migrates affected boards back to "Open" and emits a log telling you which projects were affected.

Awesome, thanks @epriestley!