As I just ran into this again spinning up another machine and had to look this up again, I'd really appreciate if a Blessed Committer could give an "Accepted" state. Thanks in advance!

so something like this might work?

In D25479#13937, @avivey wrote:

maybe use an PhabricatorSearchIntField with a default provided in the buildCustomSearchFields() ?

In D25482#13939, @speck wrote:

Was this the result of a recent change?

In T15676#14475, @avivey wrote:

What kind of operation are you doing that involves loading all tasks in a browser?

I'd really prefer not to do that. I pretty often need to work with complete search results (e.g. batch-editing), not with only the first 100 and then repeat all steps for the next 100.

In D25479#13906, @avivey wrote:

Is this the only place where we have a "Page size" exposed in the search?

Hmm I guess the Test Plan should also cover testing with Conduit. Not sure this may shake something up.

Another option would be to extend the class PhabricatorSearchTextField and make the new class PhabricatorSearchPageSizeField only overwrite function getDefaultValue(), however class PhabricatorSearchTextField is marked as final and I am reluctant to change that.

This code change adds a small star to handles of new user accounts:

Fix variable names

Obviously, any fixes should be in ManiphestTransactionEditor and not spill into generic parent PhabricatorApplicationTransactionEditor.

Historical references: rP69eab4196de462e42b07b60e2b52071631f4a3c8 and rP4041a7e0f66406dbaa31faa3807d50833b7c7efd (which didn't help much).

Probably this was moved?

If someone strongly feels that I should revert, please say so - thanks! :)

Valerio: Uhm, I'm sorry, I had not seen your comment here before I landed the patch (as I had checked my Differential page instead of my notifications).

Thanks for the additional debugging and finding steps to reproduce! In this case, I'd prefer not to log the issue and to only show a message to the user explaining what's the issue, including their requested bogus encoding.

Heh, very good catch! I can confirm, yes.

Thanks for the deeper investigation! I can confirm that with the last version and following my original steps to reproduce, no stuck daemon task about the mock looping due to an exception on http://phorge.localhost/daemon/ anymore, so I'm going to land this.

This might be a duplicate of T15636

Good points. This patch puts also the exception message into phlog.

Update per last comment

Maybe I have to test this against PHP 8.1

If this is considered too dangerous to merge, I could first test this in downstream for a while.

Initially, the task is in the project's default column:

MariaDB [phabricator_project]> SELECT cp.id, p.name AS projectName, cp.boardPHID, c.name AS columnName, cp.columnPHID FROM project_columnposition cp INNER JOIN project_column c ON cp.columnPHID = c.phid INNER JOIN phabricator_project.project p ON cp.boardPHID = p.phid WHERE objectPHID ="PHID-TASK-f6ri2kdpcvtb3yncho2n";
+-----+----------------+--------------------------------+------------+--------------------------------+
| id  | projectName    | boardPHID                      | columnName | columnPHID                     |
+-----+----------------+--------------------------------+------------+--------------------------------+
| 509 | T139396-parent | PHID-PROJ-yt43plz2cxlidyu4dlia | Backloggg  | PHID-PCOL-no7jbin6vngwkrghrmrk |
+-----+----------------+--------------------------------+------------+--------------------------------+

Would anyone be willing to give this another review? TIA