In T15640#19898, @valerio.bozzolan wrote:

Wow. Assuming the line is the one with phutil_nonempty_string($branch), why branch "main" is considered a number?

The current workaround I'm proposing is just:

BTW I think the page is reached by a crawler that is visiting a branch root on a specific commit:

Wow. Assuming the line is the one with phutil_nonempty_string($branch), why branch "main" is considered a number?

Finally got a reproducer URI in downstream:

• Broken: https://phabricator.wikimedia.org/diffusion/OSWB/branches/main/.gitignore;5a588bf0ee10546ddb9d0872d1be1bf48b3f3c07 (branches in URI).
• Works: https://phabricator.wikimedia.org/diffusion/OSWB/browse/main/.gitignore;5a588bf0ee10546ddb9d0872d1be1bf48b3f3c07 (browse in URI).

Digging deeper, the problem is specific to ProjectRemarkupRule::getObjectIDPattern. That returns:

Step 2: Remove irrelevant character class exclusions:

Disentangling that monster regex, step 1:

Indeed https://devina.io/redos-checker says the aformentioned regex is exponential time worst-case

I monkeypatched the code to print preg_last_error when the problematic preg_match returns null. The error is "Backtrack limit exhausted".

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.