I'm going to fast-track this to production since the fatal in PHI1334 is particularly unlucky (repository landing page) and I'm pretty confident the change doesn't make anything worse.

@20after4, any chance there's a stack trace for this in the webserver error logs? I can't immediately figure out how to reproduce this locally.

We don't have any customer use cases for this so I'm not interested in bringing it upstream at this time.

Thanks for the report. Fixed in D20642, which may or may not land today because of the holiday.

But we could also do it later.

You can also follow 20190412.herald.01.rebuild.php to add a migration which queues a worker to queue other workers to rebuild the index now. It's probably reasonable to do for Slowvote since installs are unlikely to have millions upon millions of these. But we could also do it later.

Just thinking out loud:

• Remove debugging code.
• Fix "oui oui".

• Use "%p" in urisprintf().

• For better or worse, there actually is an external caller in WorkboardController that slipped past me.

It's turtles all the way down. Computers don't work and all conventions and toolsets are fundamentally broken:

Here's roughly where I'm headed next. I'm planning to:

The "default" controller currently needs to "force" the URI parameters...
The "filter" controller currently needs to "force" the URI parameters...
The "apply" flow, where a new custom filter is applied...

In D12475, the "bulk edit" (then, "batch edit") stuff was added originally. This included a "Batch Edit Visible Tasks..." action that brought you into an edit workflow for every visible task on the board.