Relevant old upstream comment (from an unrelated task) that describes this problem as "ghosts in the UI":

Thanks again. My only concern is that, if somebody has a 1 trillion file(s) then the patch may lock the involved tables for an unexpected long amount of time, and you cannot really undo, without causing a massive implicit rollback.

git rebase master

Just as clarification for myself (maybe already obvious to others):

Minor clarification.

See also note in https://we.phorge.it/D25475#inline-3542 - looks like "creating a transformation" is done in many places.

In D25051#15888, @valerio.bozzolan wrote:

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

You are concerned for performance reasons because it doesn't limit the results. Right?

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

Gotcha. Probably this is generating the attachment transactions but should be "ignored on no effects":

This feature is not complete also for Conpherence AFAIK

My steps to reproduce are wrong / unclear / not always happening.

Other edges have probably been eliminated in the past. For example this one:

I had communicated these upstream (almost exactly a year ago~) and some helpful information was provided

For others reading this thread: there's some discussion going on in the thread of the patch linked above, D25419.

PhabricatorFileAttachmentQuery seems to eagerly load the object relation, however since the DestructionEngine extensions run after the object is already deleted, this fails and nothing is returned in the query. Changed to LiskDAO loadAllWhere, which also seems to use less queries in general (due to not eagerly loading), so changed the query in PhabricatorFile as well. Changed mpull to foreach per suggestion.

Please share the output of this:

In T15498#11487, @valerio.bozzolan wrote:

OK I can reproduce now. I was missing the php-gd extension for some reasons.

OK I can reproduce now. I was missing the php-gd extension for some reasons.

I'm trying to reproduce this, but in my local installation I do not have any allowed file formats. I also do not remember how to make that list available.

In T15326#11073, @Cigaryno wrote:

Do you mean PHP 8.0 or PHP 8.1? I'm confused.

Do you mean PHP 8.0 or PHP 8.1? I'm confused.

For the records, I had the same experience when deleting a repository via ./bin/remove destroy rESHP for Unknown edge constant "25" (not 26 as mentioned in the task title) in downstream https://phabricator.wikimedia.org/T119588

Another use case: Drag & Drop on a new Object description, even if the Object is not already created, should attach by default to it.

Also, trying to Upload Picture in a user Profile, not having php-gd installed leads to a confusing error message not listing any file formats:
This server only supports these image formats: .

I just realized that src/applications/config/check/PhabricatorGDSetupCheck.php exists. Thus please ignore my last comment. Still, things should fail gracefully instead of showing an exception.

Pseudo code, not tested as other exceptions block me from testing:

Just some notes for later

Hi @Dylsss thanks again for your improvement. Have you any idea about why that message happens?

No errors in the console..

By the way I understand that manually putting something like {F123} in the article should allow to manually attach that file to the Phame Post object. So, I see and agree this is a separated problem related to Phame.

Can I ask you if you are on latest version? If yes, can I ask you if you have errors in your console? if yes, see this:

I encountered this, when upgrading from Phabricator, during last step, ./bin/cache purge --all:

I start triaging this to Normal priority since this problem creates situations that don't happen with many proprietary weird alternatives like Trello, Asana etc., where their Drag & Drop "just works" since their file are always visible to all members and so it's considered as "working" for their end-users (well, thanks to the fact that Trello etc. have a terrible permission management system, thousand years back from Phorge, and they really have no concept of "single file permission", and so they win easy in these confrontations where the user expects something basic and it doesn't happen as default by some of our "attach to something" corner cases).