Removed paragraph entities are not deleted from database

Are you using latest RC of entity reference revisions?

Checked the code and i can't really see test coverag about this...

I only see a delete() on FieldItemInterface, but that itself declares it's only deleted when the host entity is deleted.
And on massageFormValues() of InlineParagraphWidget it is just killing the ones with status removed... But it doesn't delete. Instead, it just sets target_id and target_revision_id to NULL.

One important problem:
Deleting the paragraph entity is fine as long as there is no remaining usage.
Only the presence of a previous revision that has a paragraph embeddd requires us to keep it.
Thus in an environment with revisions, a paragraph is likely never deleted in regular processes.

One question is, if one simply should resolve the field item reference (host > field > paragraph entity) for such a query. But this only works for one single field.

Same here

select * from paragraphs_item_field_data;

shows 2 rows that should be deleted or at least status=0. Now they are indistinguishable from those not deleted.

I have a view that displays a single paragraph of certain type from a taxonomy term entity. There should be only one such paragraph. And now I can see the first one (deleted) even if there's none and can't see the new one if I add it.

query

SELECT paragraphs_item_field_data.id AS id
FROM 
{paragraphs_item_field_data} paragraphs_item_field_data
WHERE (( (paragraphs_item_field_data.parent_id = '9') AND (paragraphs_item_field_data.parent_type = 'taxonomy_term') )AND(( (paragraphs_item_field_data.type IN  ('countdown')) AND (paragraphs_item_field_data.status = '1') )))
LIMIT 1 OFFSET 0

DEV Paragraphs and Entity Reference Revisions (July 20/21)

Fixing the view is easy. Just add the relationship to the host entity as required and the lines of deleted hosts will disappear.

Again: For instance, if you use revisions we can not delete the paragraph ever! You can not list paragraph entities without considering the host and the paragraph field state, by design of this composite relationship.

Tanks. It's still disturbing to know the stuff I want to be deleted is never going to. I don't use revisions and in this case all I need is a single paragraph instance.
Another question, will deleting the 'host' entity help? I mean the paragraph is attached to node/term with id X, will it get wiped if I delete the X? Just curious.

@scoff The answer to your question is in #4 - although just guessing from code.
Happy to hear from you if it is correct.

Ah, finally... yeah that's why this issue exists: We want to fix it. But it's not within our priorities or not even a release blocker.
We would be happy to get help from the community to get it done though.

@scoff The answer to your question is in #4 - although just guessing from code.
Happy to hear from you if it is correct.

Ah, finally... yeah that's why this issue exists: We want to fix it. But it's not within our priorities or not even a release blocker.
We would be happy to get help from the community to get it done though.

I also just checked some revision workflows.

We also need to support deleting a host revision. I guess this is more an ERR thing...

I created a bunch of related issues at entity reference revisions:
#2771531: [META] Remove obsolete composite entities from existing storage (garbage collection)
#2771523: support host revision delete
#2771519: support host delete

I just came across this problem.
I delete the paragraph but the data stays into:

• paragraph__field_editor_name
• paragraph_revision__field_editor_name

Tried with latest dev of
http://cgit.drupalcode.org/paragraphs/commit/?h=8.x-1.x&id=c7b066229c8ea...
http://cgit.drupalcode.org/entity_reference_revisions/commit/?h=8.x-1.x&...

This is biting me hard. I need to update other entities on removal of a paragraph from its host entity, where the host entity is NOT revisioned, so the paragraph really is unused after removal. hook_ENTITY_TYPE_delete() never fires for the paragraph.

Looks like I will need to implement the update hook for the host entity and iterate through the ERR field comparing original values to updated values, right?

I have the issue with 8.x-1.1+9-dev.
If i add required relationship with parent node – i get both actual and deleted revisions.
May be we should use workaround – delete all rows
from paragraphs_item_field_data
whose id doesn't contain in
node__field_NAME.field_NAME_target_id
in hook_node_update()?

I have to say that this bug is pain in the ass.

Now I have nodes that have paragraphs with multiple referenced nodes. Every time the node is updated the views that are using those referenced nodes get wrong number of results and languages seem not to work either.

For me it would be crucial to get this issue solved so that no garbage is left to the database.

@all As the title states, it's a bug and it's still there. I hear complains and about workarounds, but no one is contributing to fix the root cause.

We raised the priority to the pain accordingly, but it doesn't affect us or our projects, so we didn't fix it yet. We already spent too much time fixing all the things for free. Yes, more than a man-year of work.

Either someone provides a merge request or hires a dev or provides funds to maintainers to fix it. In any case, we will review it and release the pain, given there's test coverage and the approach is OK. But if i see more complains i might unsubscribe from this issue.

For me, my node__ field tables are not even getting the 'deleted' flag set to 1. I also do not have a way in Views to filter by deleted state. If a Paragraph is not reused, why can we just not set the deleted flag to 1 in the database when "Confirm removal" is clicked? To me you are effectively breaking the relationship off of the host entity there.

I also see in paragraph_item_field_data and paragraph_item_field_revision_data that the 'status' field is never set to 0 either when a paragraph is removed from a node.

Does anyone have a workaround?

The only workaround I can think of is to:

1. Query and build an array of all the ids in column field_xxx_target_id of {node__field_xxx}. These are the ids we want to keep, I think.

2. Implement hook_ENTITY_TYPE_update and iterate over all the necessary {paragraph__field_section_xxx} and {paragraph_revision__field_section_xxx} tables, setting deleted to 1 where field_sections_target_id is not in the array built in 1.

Like in #15.

I haven't tried this yet, but I need a workaround asap, because I cannot exclude deleted data from my view, which was my preference.

I think the view can be handled by adding a handler/filter plugin on 'deleted' - but that doesn't ever seem to get set for me anyway. Not sure why.

If you create a Node based View and relate paragraph to it, it takes "deleted" into account for you (view the query - its filtering on deleted = 0). If you create a Paragraph based View, there is no way to filter on it.

@24ma13wg @kevinquillen You don't need a workaround. You want to extend our tests to proof the bug and then fix it with a patch in Paragraphs and apply that patch to your instance. These days, temporarily applying such a patch with composer until it's committed is super simple.

It's likely that a custom module workaround is more complex than a fix / improvement in Paragraphs.

Okay, I am not too familiar with the codebase, but I followed along with xdebug after clicking "REMOVE" or "Confirm Removal" on the paragraph field widget.

When "Confirm Removal" is hit, IMO the paragraph status should be set to 0. I have never used translation or other related modules, so I don't know how practical this is, but on line 1289 of InlineParagraphWidget.php there is code that knows removal was triggered, but doesn't write to the paragraph being removed:

      // If our mode is remove don't save or reference this entity.
      // @todo: Maybe we should actually delete it here?
      elseif($widget_state['paragraphs'][$item['_original_delta']]['mode'] == 'remove' || $widget_state['paragraphs'][$item['_original_delta']]['mode'] == 'removed') {
          $item['target_id'] = NULL;
          $item['target_revision_id'] = NULL; 
      }

As a start, I added this inside that block:

        // paragraph was removed, set status to 0
        $paragraphs_entity = $widget_state['paragraphs'][$item['_original_delta']]['entity'];
        $paragraphs_entity->set('status', 0);
        $paragraphs_entity->save(); // this saves and status is set to 0

Using save() set the status to 0 and I can see that reflected for that paragraph item in the database.

I then added "Published = TRUE" as a filter in the View I am using, and I got what I expected to see in my use case.

I guess one thing would be how to set status through nested paragraphs..

Attaching my current patch. Needs tests... not sure where to start yet.

Updating with link to this issue in the comment above the code.

Clicking 'Remove' and then 'Restore' - the status is stuck on 0. There are two options, either 'Restore' is treated as a special mode (currently 'edit') or we can just ensure status is set in the edit mode. Patch updated.

We spent a lot of time to remove all save operations during the widget lifecycle and this is the route to go.

If you set a breakpoint to the save operation, you will see that it is triggered without your patch only when the host entity is saved.

Right at that moment, we need to deal with deleted elements.
If for instance those deleted elements are now skipped completely, then we need to identify/filter them in comparision to the original host and perform the transition on them.

Hope this helps as a next step?

Instead of trying to fix the bug, just writing a test scenario that proofs the bug / non-fulfilled expectations would be at least as helpful.

Any progress here?

Got bit by this bug today while trying to build Salesforce support for paragraphs.

I can also confirm this bug still exists. Just ran into it.

Is the paragraph widget the right spot for this logic?
Wouldn't this be better in the storage or entity layer?

Also: this only addresses the scenario where the paragraph is removed from a parent entity.
This doesn't address the scenario where the parent entity is deleted.

Can we address both those scenarios in this thread, or do we need a new issue for the latter?

@aaronbauman I pointed exactly at the storage related issues in Entity Reference Revisions #2741937-12: Removed paragraph entities are not deleted from database

The next milestone here is to write a test.

Ah, thank you for the pointer.
I will followup on that issue as well.

Additionally, this patch only fixes one widget -- InlineParagraphsWidget.
Probably should fix ParagraphsWidget as well.

If anyone else is impatient on this issue, I made a little module to do the job for me:
https://www.drupal.org/project/paragraphs_clean

If it were that easy then we'd have done it already :)

Your module ignores revisions for example, when saving as a new revision, then you must not delete the old paragraphs. And now with the drag and drop reorder, it's possible that a paragraph is from the parent into a nested paragraph, so it will vanish from that list but still be used elsewhere. That's practically impossible to know at the time of saving, the "removed" paragraph might have been saved earlier or has not been saved yet.

The only reliable approach to this would be to add saved entities to a queue and then compare saved paragraphs and their parent references to what's still being used, but that too needs to consider all revisions.

ERR has a test and several open issues about different use cases with translatable and untranslate fields about deleting translations/revisions/entities when the parent is deleted. That's what we should focus on as a start.

right, that's why i called out especially "rudimentary" and "naive"
my use case is simple enough that I don't have to worry about revisions or paragraphs-referencing-paragraphs, fortunately.

I'll add these caveats to the project description - thank you! please let me know here, or in the issue queue over there, if you think of any more that should be called out.

Prevent to create paragraphs by deleting the unsaved paragraph.

@Berdir Should we start to postpone these issues for the intended first steps in ERR?

@aaronbauman Are you going to further work on this topic or its predecessors in ERR? The issue is still assigned to you.

thank you for the nudge.
i'm not clear on the best way forward, so someone else please jump in

Thanks all, but none of the patches did not work
Drupal 8.4.5 / Paragraphs 8.x-1.2

@aaronbauman 37 your solution works like charm! i tested it at my end!

I also had the forementioned problem. My view showing paragraphs also listed deleted references. The solution from answer #4 did not solve it for me. I was able to work around this problem in my specific case by using a view showing content instead and relating that content to the paragraph by configuring view relationships.

1. make a content view (not a paragraph view)

2. add a relationship from the content fo the paragraph
In the case of Michèle : Paragraph referenced from field_paragraph_news (Require this relationship)

3. add fields from the paragraph to the view

4. remove the initial content fields that were there when you created the view

5. in case you have entity reference fields in your paragrahph, you can add a filter to remove unspecified references
machine_name_of_field_in_paragraph_having_entity_reference : IS NOT EMPTY (NOT NULL)

Thanks all.

I did following steps to overcome this problem.

- Implemented Paragraphs Clean module (https://www.drupal.org/project/paragraphs_clean). This removes paragraph entity on node save instead of making it orphan when you remove paragraph entity in node. Please keep in mind, this module doesn't do anything to existing orphan paragraph entities, it only helps for future records.

- To exclude existing deleted paragraph entries (orphan paragraph) in views, added parent node (host entity) as required relationship.

- I know there are orphan paragraph entries (garbage) sitting in table, I need to find and delete those manually in database.

Just a tiny thing about paragraphs_clean module: I guess that a revert of a previous revision would then not bring back deleted Paragraphs, making the whole idea of our underlying "Entity Reference Revision" storage flawed.

Thanks for those calling out those caveats - "paragraphs clean" is not compatibile with paragraph revisioning.
There may also be problems with multilingual sites as well.
It solves only the simplest use case.

It's meant to be a stop gap until the broader, much more complex fix in here gets some attention.

I am also facing the same issue.Deleted paragraph showing in the view.

Seems like a pretty big problem especially if one uses Layout Builder and views with contextual filters on a node ID to bring in blocks of content that use Paragraphs.

I've found that Views tend to also can get stuck on the original paragraph and ignore revisions as well as this problem of the Paragraph remaining in the system even after being removed.

I'm not sure where the problem should be attacked from. Is this a paragraphs issue or is it an Entity Reference Revision issue?

There are some issues that are trying to fix this problem. See #2771531: [META] Remove obsolete composite entities from existing storage (garbage collection). However, those fixes will only be possible if we are able to make the parent fields of the paragraphs entity, revisionable. See #3041759: Parent field revision rebuild.

I think the right approach here is to add a field / filter to check if the paragraph is currently used and active for views / context. It's important for revisions to keep old paragraphs - we just need to know if the paragraph is active and filter by that.

The workaround, as already mentioned, it to start the view from the parent entity instead and work from relationships to the paragraphs - this works better. I think also adding this caveat in the documentation would be a good idea.

I am also facing this problem with a decoupled website that I am working on. I do not use revisions but i have enabled another language. Deleting a paragraph within a parent node does indeed remove the paragraph from the list on the parent node edit page, but when making a JSONAPI request for retrieving the paragraphs (of the same type ofcourse) I still get the deleted paragraphs included in the response. Checking the database reveals that they are indeed still stored. I understand why this is, the reference to the paragraph is removed but the paragraph itself is still stored, and that querying paragraphs by using the parent relationship gives the correct active paragraphs. But, we still have our orphans to deal with!

It is very strange how a bug of this magnitude still goes unnoticed and left lingering. I see many companies boasting about this module even though a basic feature such as "delete paragraph" isn't supported! If a permanent fix is not easily achievable then at least someone should propose a temporary "at your own risk" sort of fix. Anyone? I tried the paragraphs clean module which on paper seems to be exactly what I need, but did not delete my paragraphs. Maybe because I have enabled another language and the author of this module said it might not work on multilingual sites. In that case would it be possible to extend the clean paragraphs module to support multilingual sites? From a code perspective is seems simple to just iterate through the relevant table(s) if other languages are enabled and delete the paragraphs for them too. And just add a disclaimer that this does not support revisions.

Reading this entire issue it seems that the major culprit is revisions. So if we can support deleting paragraphs on multilingual sites then we are catering for more use cases.

Put the following code into a custom module and watch your orphaned paragraphs scream as they get blown away! Even if you have revisions and translatable enabled, they get terminated. Database is now nice and clean.

Note that the sql query from the code can be modified to suit your needs. Lets say that you attach paragraphs to another entity (not nodes), then just modify the query to look for your entity.

<?php

use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Entity\FieldableEntityInterface;
use Drupal\field\Entity\FieldConfig;

/**
 * Implements hook_entity_update().
 * 
 * When form updates, delete any paragraph entities that were removed.
 * 
 * @param \Drupal\Core\Entity\EntityInterface $entity
 */
function mymodule_node_update(EntityInterface $entity) {

  // Only act on content entities.
  if (!($entity instanceof FieldableEntityInterface)) {
    return;
  }
  
  $fieldManager = \Drupal::service('entity_field.manager');
  $parentEntities = $fieldManager->getFieldMapByFieldType('entity_reference_revisions');

  if (!array_key_exists($entity->getEntityTypeId(), $parentEntities)) {
    return;
  }

  $paragraph_definitions = [];

  // loop through all paragraph types
  foreach ($parentEntities[$entity->getEntityTypeId()] as $field_id => $settings) {
    if ($configField = FieldConfig::loadByName($entity->getEntityTypeId(), $entity->bundle(), $field_id)) {
      $paragraph_definitions[] = $configField;
    }
  }

  if (empty($paragraph_definitions)) {
    return;
  }

  foreach ($paragraph_definitions as $paragraph_definition) {
    
    // Remove orphaned paragraphs.
    $query = \Drupal::database()->select('paragraphs_item_field_data', 'pfd')
      ->fields('pfd', ['id'])
      ->condition('pfd.parent_type', 'node')
      ->condition('pfd.parent_id', $entity->id())
      ->condition('pfd.parent_field_name', $paragraph_definition->getName());

    $query->addJoin('left','node__'.$paragraph_definition->getName(),'nt','pfd.id=nt.'.$paragraph_definition->getName().'_target_id');
    $query->isNull('nt.'.$paragraph_definition->getName().'_target_id');
    $query->distinct();

    $paragraph_ids = $query->execute()->fetchCol();
    
    if ($paragraph_ids) {
      $para_storage = \Drupal::entityTypeManager()->getStorage('paragraph');
      foreach ($paragraph_ids as $paragraph_id) {
        
        if ($para = $para_storage->load($paragraph_id)) {
          $para->delete();
          drupal_set_message(t('Paragraph of type "%type" has been deleted: %id', ['%id' => $paragraph_id, '%type' => $paragraph_definition->getName()]));
        }

      }
    }    

  }

}

I have the same issue and patches and code from #53 didn't work for me. I've created a simple patch which works perfecty and it's very basic.

Good luck!

Thank you so much @javitan.

You're patch #54 works great for me with Paragraphs 8.x-1.8 and Drupal 8.7.5

The patch from @javitan reveals where it is possible to delete an orphaned paragraph. However there are two issues here:

1. There are two files within the paragraph module that have similar code in which one could delete an orphaned paragraph, Files are:

paragraphs/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
paragraphs/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php

...both have a method massageFormValues() where we could delete paragraphs. Do we add the code in both?

2. Adding a patch now to the contrib module would mean loosing this functionality during a module update. Just make sure you keep track of this patch in the event that you would update this module to a later version.

To be clear, I do not recommend to use anything like that. For starters, that will delete the paragraph the moment you click on delete, even if you then don't save the node for example.

A module was posted earlier that does something similar: https://www.drupal.org/project/paragraphs_clean.

In #36, I pointed out possible reasons why you shouldn't use this, revisions/content moderation being the most obvious one.

There are various issues open in ERR that we're working on to continuously improve this, next step is committing a manual process to do that cleanup and then build on that API to improve our automatic cleanup.

As paragraphs maintainer, I advice against using that patch or that module. Changes are high that you will lose stuff sooner or later because of that.

Just jumping in to echo what Berdir says: paragraphs_clean is a stopgap module with major caveats, and not appropriate for significantly complex sites.

To solve this in a way that's compatible with core features is an intricate problem. I've tried to make this clear on the paragraphs_clean project page - please read it before installing.

What I find most problematic is not that old paragraphs are kept for a while in the database. I can see the reasons for that (old revisions etc.). But there doesn't seem to be an easy way to check (or even better query/filter with an SQL condition) if a paragraph is still in use. This would be very valuable information in many cases. Quite frequently we have the problem here that we need to know whether a paragraph is still in use (and I don't mean "in use" due to historic information like revisions).

I've written a script which goes through all paragraph entities and recursively traces the parent chain to find out whether it leads to an actual entity - but it's quite cumbersome and SLOW :-( And if you can follow up the parent chain, it still doesn't mean that the paragraph is also linked in the other way round (i.e. down the children chain). I understand where all this is coming from but I think it's very difficult to handle for us developers in many situations and can break all to easily.

And when you finally decide that you really want to get rid of a paragraph type, there should be some "sensible" way forward... Just my 0,02€

What berdir said:

"that will delete the paragraph the moment you click on delete, even if you then don't save the node for example."

... is enough not to use that code.

In my opinion, as a quick low risk solution for now:

- If you are attaching paragraphs to a node
- If you are attaching only one level down and not nesting paragraphs within paragraphs (ie. parent node -> child paragraphs... no more descendants)
- If you don't use or care about paragraph revisions.

.. just add the code from #53 to a custom module and you are done. Once this issue is resolved in the contrib paragraph module all you'd do is update the Paragraphs module and disable this custom module. If anyone sees this as a bad temp solution, given the conditions stated above, then please chime in.

Note that the sql query from the code can be modified to suit your needs. Lets say that you attach paragraphs to another entity (not nodes), then just modify the query to look for your entity.

> But there doesn't seem to be an easy way to check (or even better query/filter with an SQL condition) if a paragraph is still in use.

If you use paragraphs regularly through a field formatter then that is absolutely reliable, you get the correct revision of all the paragraphs that are really referenced in the host entity (revision) that you are displaying.

What's not working is if you do something with views or custom code that doesn't reference through the field but the parent reference fields for example. For views, there has been an issue open for a long time (#2799479: Views doesn't recognize relationship to host) that basically just needs tests afaik. Since that is not a use case that we rely on, we haven't worked on that ourself. But if anyone either works on tests or sponsors us or someone else to work on that then we'd be happy to commit that.

The parent fields are tricky, the only way to reliable solve that would be to also store the host revision ID if applicable, however, that would be a big performance hit on saving, because we would need to save all paragraphs twice, first save the new paragraph revision, then let the host be saved with the reference to that revision, then update the paragraph again with the revision ID of the host. We might be able to optimize that with custom storage methods, but that is unlikely to happen soon.

I am working with search_api, and after deleting all of my nodes on a dev env, I noticed that the search index was still going through thousands of items to index.

I installed paragraphs_clean, but to my chagrin, I noticed that it only runs when the parent entity is saved (it uses hook_entity_update). Is there any other stop-gap out there that can delete orphan paragraphs?

Backporting and deleting all of the content nodes takes about half an hour; I would like to avoid this if possible.

You're looking for #3016388: Manual cleanup process for obsolete composite entities which will be committed soon.

I did look at the patch Berdir mentioned and just to save time for anyone else who's wondering how it works: It seems the patch in #3016388 will add a new menu item to the admin config menu where you will be able to trigger the cleanup process. Sounds cool to me. This will remove a LOT of cruft.

Hello,

Comment #63's related issue's feature "Orphaned Paragraph cleanup" has been commited to entity_reference_revision 1.7.

But this doesn't fix my views' problem which display removed paragraphs. Even though comment #54's patch is a bad workaround regarding its review (comments #57 & #60), I've made a paragraph 8.x-1.9 version out of it. I'll try comment #53's code but, in a different module, this is harder to maintain.

Since the attached patch has big drawbacks especially when used on existing entities as per my experience, in plus of the limits explained in #57 & #60, it must not be used on production sites.

DO NOT USE IN PRODUCTION

Hello,

I've finally managed to implement what Berder suggests in #61 thanks to explanations in #2999730#comment-12775116.

I had to update drupal to 8.7.8, paragraphs to 1.9 & entity_reference_revisions to 1.7 (their latest stable release to date), apply the patch from #2799479#comment-12620465, reconfigure the whole view, and get rid of a nasty hook_views_query_alter() which was quietly corrupting my results.

#65 & 54 are definitely not solutions.

Regards

My recommendation for Views is to start from the entity referencing the paragraph and use relationships. This is fail-safe.

I'm closing this as a duplicate.

The referenced issues in ERR have mostly been solved, but the queue/approach will not result in immediate deletion. As confirmed by #66, when using views, you'll need that ERR issue to have correct relationships.

Wait @Berdir, if this is a duplicate, where is the ongoing issue being discussed/resolved?

@TheJDexp Should be this issue https://www.drupal.org/project/entity_reference_revisions/issues/2771531

@daveiano Thank you!

(Just adding notes to the issue summary for those of us who land here, hope that's all right.)

I've created a simple patch which works perfectly for latest version of the module

Are there no unintended consequences to the patch at #73?

Of course there are, that is far from "working perfectly", the paragraphs and all its revisions is completely _gone_ as soon as you press delete, even if you don't actually save, even from old revisions (also if you save as a new revision, or a draft). Don't use that.

Paragraph deletion should work fairly well now with latest versions of paragraphs and ERR, revisions and paragraphs will be deleted if their parent (revision) is deleted, with usage checking, and there's a batch process to clean up existing structures.

Let's not display #73 in the summary eh?

(#76: good call, thank you for thinking of that, @John Pitcairn!)

#75: yikes, unnecessarily harsh toward someone just trying to help -- totally makes sense to be crystal clear in warning users not to use the patch, but there's no need to use that kind of tone.

#67
Dubs, thank you for forcing me to lift the veil from my thought process. This is exactly what I needed to do, to avoid displaying deleted Paragraphs in a View.

> #75: yikes, unnecessarily harsh toward someone just trying to help -- totally makes sense to be crystal clear in warning users not to use the patch, but there's no need to use that kind of tone.

Sorry if that sounded harsh, but I've been saying the same thing many times in this and other issues. and people keep posting dangerous patches that will result in someone else losing data. That can be a bit frustrating ;) So I think it's also important to be very clear about not using such a patch.

> #68 Please clearly refer to an issue this one has marked for as duplicate so that people can clearly follow up on the one in progress. Otherwise marked as duplicate is confusing on researching the issue. (Sadly even I can't do it since even for me it is not clear which one it should be here)

The main issue has been mentioned in comment #70: #2771531: [META] Remove obsolete composite entities from existing storage (garbage collection)

Since there have been mentioned multiple issues I wasn't sure which you or we should prefer. Thanks Berdir! Marked as duplicate (again) in favor of: #2771531: [META] Remove obsolete composite entities from existing storage (garbage collection)