Page History

...

1. Log a warning
2. Move the partition's directory to log.dir/deleting/{topic_id}_{partition}.
3. A final deletion event will be scheduled for X ms after the LeaderAndIsrRequest was first received. This will clear the deleting directory of the partition's files.

Migration

When a broker receives a LeaderAndIsrRequest containing a topic ID for an existing partition without an associated topic ID, it will associate the topic ID with the partition. This will effectively migrate a broker's local replicas to include topic IDs.

LeaderAndIsrResponse v3

...

This strategy would allow brokers to effectively delete topics immediately, ensuring deletions do not block creation and use of a new topic with the same name. This  This is the optional proposed by this KIP , that will clean up the deletion to remove the current blocking deletion and creation logic and simplify the topic deletion and creation flow. 

Upon receiving a DeleteTopicsRequest, if the IBP is >= MIN_TOPIC_ID_VERSION move the /brokers/topics/[topic] znode payload to /admin/delete_topics_by_id/[topicId], and immediately reply to the DeleteTopicsRequest with a successful response. At this point, the topic is considered deleted, and a topic with the same name can be created.

...

For the time being, we may wish to use the latest protocol versions with clients that do not support topic IDs yet. Until the clients have been updated to refer to partitions by topic ID, we should include both topic name and (optional) ID in every request.

Migration

When a broker receives a LeaderAndIsrRequest containing a topic ID for an existing partition without an associated topic ID, it will associate the topic ID with the partition. This will effectively migrate a broker's local replicas to include topic IDs.

Storage

Partition Metadata file

...