[HUDI-5529] Ensure that consistent hashing metadata is purged when dropping a partition

[voonhous]

Change Logs

Eagerly attempt to purge the partition metadata that has been dropped using the ALTER TABLE DROP PARTITION DDL to prevent data from being written itno filegroups that are flagged for deletion.

Issue is described in detail here: #7634

Impact

No impact

Risk level (write none, low medium or high below)

LOW

Documentation Update

Describe any necessary documentation update if there is any new feature, config, or user-facing change

• The config description must be updated if new configs are added or the default value of the configs are changed
• Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
  ticket number here and follow the instruction to make
  changes to the website.

Contributor's checklist

• Read through contributor's guide
• Change Logs and Impact were stated clearly
• Adequate tests were added if applicable
• CI passed

[voonhous]

TBH, i don't think this is a very good approach.

This is a non-atomic action, and if there are many partitions to iterate over, and the ALTER TABLE DROP DDL fails mid-way, subsequent writes might mess the table up in an unfixable manner.

Instead, i think we should re-initialise the consistent hashing meta (if required) when performing the writes.

[voonhous]

Okay, re-did the fix with a re-create consistent hashing meta logic instead of deleting consistent hashing metadata logic.

[hudi-bot]

CI report:

• b4353d0 UNKNOWN
• 6246548 Azure: FAILURE

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build