Fix flush deletes

[jiangxinmeng1]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #15959

What this PR does / why we need it:

Not check whether object is dropped when flush deletes.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

jiangxinmeng1 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[matrix-meow]

@jiangxinmeng1 Thanks for your contributions!

Pull Request Review:

Problem 1: Lack of Object Dropped Check in PrepareCompact Function

In the PrepareCompact function of ObjectEntry in object.go, the check for whether the object has been dropped is removed. This can lead to potential issues if the object has been dropped but the function proceeds as if it hasn't. It is crucial to ensure that the object's dropped status is considered before proceeding with compacting operations.

Solution 1:

Reintroduce the check for HasDropCommittedLocked() in the PrepareCompact function to ensure that the object is not compacted if it has been dropped. This will prevent unnecessary operations on dropped objects and maintain data integrity.

Problem 2: Missing Metadata Check in GCByTS Function

In the GCByTS function of Catalog in catalog.go, there is a new call to CheckMetadata added without proper context or explanation. It is important to provide a clear rationale for this addition and ensure that it is necessary for the functionality of the code.

Solution 2:

Add a comment or documentation explaining the purpose of calling CheckMetadata in the GCByTS function to clarify its necessity. Ensure that this addition is justified and aligns with the overall design and requirements of the codebase.

Problem 3: Unhandled Panic in CheckFlushTaskRetry Function

In the CheckFlushTaskRetry function of baseObject in base.go, there are new panic statements added without proper error handling or recovery mechanisms. Panicking in this context can lead to abrupt termination of the program and potential data corruption.

Solution 3:

Instead of panicking, consider returning an error or implementing a more graceful error handling strategy in the CheckFlushTaskRetry function. This will help maintain the stability of the application and prevent unexpected crashes.

Problem 4: Inconsistent Handling of Object Drop Status in PrepareCompact Function

In the PrepareCompact function of aobject in aobj.go, the handling of dropped objects is inconsistent. The logic for checking dropped status and preparing for compacting should be unified and streamlined to ensure clarity and maintainability.

Solution 4:

Consolidate the logic for handling dropped objects in the PrepareCompact function of aobject to ensure consistency and readability. Ensure that the code follows a clear and coherent approach to handling dropped objects during the compacting process.

Optimization:

Consider adding comments or documentation to explain the purpose and rationale behind the changes made in the pull request. This will help future developers understand the code modifications and the reasoning behind them. Additionally, ensure that the changes adhere to the project's coding standards and best practices for improved code quality.

By addressing the identified problems and optimizing the changes, the pull request can be enhanced to ensure the stability, security, and maintainability of the codebase.