This exception happens once $rule in the loop foreach ($this->getMarkupRules() as $rule) in PhutilRemarkupBlockRule::applyRules($text) becomes ProjectRemarkupRule. That's where it blows up.

Maybe interesting, there is this different non-deprecated API:

This is an issue in https://we.phorge.it/source/phorge/browse/master/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php . In getObjectEmbedPattern(), preg_quote($prefix) returns \# and the method finally returns (\B{\#([^.\s?!,:;{}#\(\)"'\*/~]+(?:[^\s?!,:;{}#\(\)"'\*/~]*[^.\s?!,:;{}#\(\)"'\*/~]+)*)([,\s](?:[^}\\]|\\.)*)?}\B)u.
Within apply($text), $text becomes null after that first preg_replace_callback, so the second call barks.

I'm not skilled enough to look into the bigger picture, however maybe the Edit Column dialog could have a third field apart from Name and Point Limit to also have Task Limit (or Card Limit?). Point Limit and Task Limit then must be mutually exclusive (do not allow to set both for a column, or even...board?), somehow.

I do not (yet?) understand the use case of this task.

Indeed reported from a Wikimedia user about Wikimedia Phabricator.

It seems to me that this problem can be solved with an additional setting that turns this functionality on or off.

It might not happen on any other card, because we might not be rendering Remarkup on any other card. Interesting....

So this is quite an edge-case:

• PhabricatorMentionRemarkupRule wants to give the mention a different color, depending on if the user can view the "context object", in this case the Project.
• There's an automatic rule, saying a member of a project can always view the project
• When loading the project for the hovercard, we don't bother loading all the member list
• When loading the user for the mention, we don't bother loading all its projects
• so data is not available at the rendering point.

Another good simple candidate GDPR-friendly:

Ouch

Also note that we have a similar PhabricatorDataNotAttachedException in PhabricatorRepositoryCommit (via getRepository()) in downstream https://phabricator.wikimedia.org/T360714. It's without reproduction steps but sounds a bit similar.

Maybe unrelated. But after we fix PhabricatorCursorPagedPolicyAwareQuery, maybe we will find a crash test also for the first two lines:

Interestingly I was able to reproduce, but only creating 101+ tasks manually and going to the next page. So after that ?after=100 is introduced.

Here's another one that I think deserves to be upstreamed: https://phabricator.wikimedia.org/T230787 adds context and search term highlights to fulltext search results. Currently Phorge and upstream Phabricator only show matching document titles with highlights on keywords in the title but not the body.
The efficiency of my solution is questionable, however, it's working well enough for Wikimedia's use of the feature.

there is a presentation from eric brechner, who was in microsofts xbox development, about kanban. he does it on whiteboard, extremely sinple:
https://www.youtube.com/watch?v=CD0y-aU1sXo