GA maven-metadata.xml fails to refresh if a GAV is deleted via Browse's "Delete Folder" button

In a maven hosted repository, perform the following steps

1. Upload multiple base versions of a component under the same GA. For example if this is a snapshot repo, the resulting Browse view could look like:
   • com/example/project1/1.0.0-SNAPSHOT
   • com/example/project1/2.0.0-SNAPSHOT
2. Observe that the file at com/example/project1/maven-metadata.xml contains reference to both base versions.
3. In the browse UI, select one of the GAV nodes. For example select com/example/project1/1.0.0-SNAPSHOT. On the right hand sidebar there is a button to "Delete folder". Click the button.
4. Wait a few seconds to account for any eventual consistency
5. Download the GA level maven-metadata.xml again, notice that it is still referencing the deleted baseVersion 1.0.0-SNAPSHOT.
6. The GA metadata remains incorrect ( referencing a non-existent base version ) until it is marked for rebuild using some other method, or rebuilt explicitly using the Maven - Rebuild metadata task.

Reproduce:

Expected

Deleting a baseVersion using Delete folder button should cause the GA level maven-metadata.xml to be accurate on the next download of it, without performing a manual rebuild of the metadata.

Alternate method that does not trigger the invalid metadata

To successfully delete an entire GAbaseVersion node manually, select and use "Delete component" button for each timestamped version under the GAbaseVersion folder. After all GAbaseVersion/timestampedVersion versions are deleted, then the maven metadata will be accurate.

Another method is to use the cleanup policies and tasks to delete old GAVs no longer needed. When these tasks are used, then the corrupt metadata also does not happen.

Additional Notes

If you trigger the rebuild in another way, e.g. using the "Delete Component" on a GAV timestamped snapshot version, then the rebuild GA maven-metadata.xml will have the correct content. 

Another thing that I noticed was that the files differ in some other ways as well. The original file lacks the metadata->modelVersion and metadata->versioning->latest

After Folder Delete

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>jtt</groupId>
  <artifactId>jtzapp</artifactId>
  <versioning>
    <versions>
      <version>1-SNAPSHOT</version>
      <version>2-SNAPSHOT</version>
      <version>3-SNAPSHOT</version>
      <version>4-SNAPSHOT</version>
      <version>5-SNAPSHOT</version>
      <version>6-SNAPSHOT</version>
      <version>7-SNAPSHOT</version>
      <version>8-SNAPSHOT</version>
      <version>9-SNAPSHOT</version>
      <version>10-SNAPSHOT</version>
    </versions>
    <lastUpdated>20210326223253</lastUpdated>
  </versioning>
</metadata>

After Component Delete and Folder Delete:

<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
  <groupId>jtt</groupId>
  <artifactId>jtzapp</artifactId>
  <versioning>
    <latest>10-SNAPSHOT</latest>
    <versions>
      <version>1-SNAPSHOT</version>
      <version>2-SNAPSHOT</version>
      <version>3-SNAPSHOT</version>
      <version>4-SNAPSHOT</version>
      <version>6-SNAPSHOT</version>
      <version>7-SNAPSHOT</version>
      <version>8-SNAPSHOT</version>
      <version>10-SNAPSHOT</version>
    </versions>
    <lastUpdated>20210326220703</lastUpdated>
  </versioning>
</metadata>
 

This was reproduced on 68e1b2c4c306a51d53c56e1f3956ab2bb44fe824 before I had merged in my metadata changes.