Yep. I'm up-to-date with master as of filing the issue^^.
This textbox isn't a Remarkup field (it's actually a ConpherenceDurableColumnView, which doesn't even have a metadata field in the first place)
In normal Conpherence views, the "Upload file" button works just fine. (except as mentioned in Z1, where reloading the page erases the metadata field)

Thanks. Can you reproduce with "Upload file" button too? If yes, maybe sub-task of: T15106: "Upload file" in remarkup text fields should attach by default

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.

This is becoming quite frustrating in my workplace in Torino. Let's start immersion mode.

The solution was to take direct children project and call $child->setParentProjectPHID($my_parent_phid).

Finally in my Phorge I can kill these milestones \o/

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.

Yep. In all cases it's at least a full-table-scan on file_attachment. Probably a bit more RAM-efficient with the NOT EXISTS thing since it does not need to have all file PHIDs in memory.

My userbase is stellar in relentlessly clicking every button you provide them :P

(Wow. I've never clicked on that button in my life, also when working)

Thanks :) Interesting weird transaction.

I'd be worried about DB performance running such a query as our DB has dozens of millions of files... (This is basically SELECT COUNT(*) FROM file_attachment fa WHERE fa.filePHID NOT IN (SELECT f.phid FROM file); in my understanding?)

Unrelated but @aklapper I'm curious about the situation in WMF. If you can maybe report something like this:

I haven't looked at Phorge's internals much yet, but perhaps the user could unmark a task as duplicate, or have the "Close As Duplicate" box be prefilled with the task that closed it and let the user deselect that and choose another one?

Once we remove this, we'll need to handle this edge-case:

• I've closed a ticket as "duplicate of T1", but I was wrong and want to mark it as "duplicate of T2" instead (and say it's not a dup of T1).

Partially related to T15822: When a phriction page is moved, history should follow the page move

OK. Well, thaanks \o/