additional logic for historic plugin

Signed-off-by: Atanas Atanasov <a.v.atanasov98@gmail.com>

Author: ata-nas

block-node/block-providers/files.historic/src/main/java/org/hiero/block/node/blocks/files/historic/BlocksFilesHistoricPlugin.java

@@ -8,6 +8,7 @@
 import java.io.IOException;
 import java.lang.System.Logger.Level;
 import java.nio.file.Files;
+import java.nio.file.Path;
 import java.util.List;
 import java.util.Objects;
 import java.util.concurrent.CopyOnWriteArrayList;
@@ -44,6 +45,8 @@ public final class BlocksFilesHistoricPlugin implements BlockProviderPlugin, Blo
     private final CopyOnWriteArrayList<LongRange> inProgressZipRanges = new CopyOnWriteArrayList<>();
     /** Running total of bytes stored in the historic tier */
     private final AtomicLong totalBytesStored = new AtomicLong(0);
+    /** The config used for this plugin */
+    private FilesHistoricConfig config;
     /** The Storage Retention Policy Threshold */
     private long retentionPolicyThreshold;
 
@@ -74,7 +77,7 @@ public List<Class<? extends Record>> configDataTypes() {
     @Override
     public void init(final BlockNodeContext context, final ServiceBuilder serviceBuilder) {
         this.context = Objects.requireNonNull(context);
-        final FilesHistoricConfig config = context.configuration().getConfigData(FilesHistoricConfig.class);
+        this.config = context.configuration().getConfigData(FilesHistoricConfig.class);
         this.retentionPolicyThreshold = context.storageRetentionPolicyThreshold();
         // Initialize metrics
         initMetrics(context.metrics());
@@ -198,6 +201,11 @@ public BlockRangeSet availableBlocks() {
     public void handlePersisted(PersistedNotification notification) {
         if (notification.blockProviderPriority() > defaultPriority()) {
             attemptZipping();
+            // @todo(1268) like in the recents plugin, should we cleanup only if the priority check passes?
+            //   here I think yes, because we only get new data if the check passes, so there is no issue
+            //   to keep within the bounds of the retention policy threshold. But for the recents plugin,
+            //   maybe we need to think about it since it gets new data via the verification notification.
+            cleanup();
         } // todo this is not enough of an assertion that the blocks will be coming from the right place
         //     as notifications are async and things can happen, when we get the accessors later, we should
         //     be able to get accessors only from places that have higher priority than us. We should probably
@@ -226,6 +234,32 @@ private void attemptZipping() {
         }
     }
 
+    private void cleanup() {
+        final long totalStored = availableBlocks.size();
+        long excess = totalStored - retentionPolicyThreshold;
+        while (excess >= numberOfBlocksPerZipFile) {
+            // if we have passed the above check, we can delete at least one zip file
+            // we assume there are no gaps in the zips, the number of blocks per zip file
+            // setting is not possible to change after starting the system for the first time,
+            // also the number of blocks per zip file is a power of ten, so we can safely
+            // say that whatever the range is, it will always start/end with a predictable number
+            // e.g. 0-9, 10-19, 20-29 (batch 10s) or 10_000-19_999, 20_000-29_999 (batch 1000s) etc.
+            // depending on the setting
+            final long minBlockNumberStored = availableBlocks.min();
+            // no need to compute existing below, we need the path to the zip file, we do not need to
+            // check if it exists, moreover we do not need to know actual block compression type.
+            final Path zipToDelete =
+                    BlockPath.computeBlockPath(config, minBlockNumberStored).zipFilePath();
+            try {
+                Files.deleteIfExists(zipToDelete);
+            } catch (final IOException e) {
+                throw new RuntimeException(e);
+                // @todo(1268) what to do here if we cannot delete the zip file?
+            }
+            excess -= numberOfBlocksPerZipFile;
+        }
+    }
+
     /**
      * Start moving a batch of blocks to a zip file in background as long as batch is not already in progress or queued
      * to be started.

block-node/block-providers/files.recent/src/main/java/org/hiero/block/node/blocks/files/recent/BlocksFilesRecentPlugin.java

@@ -258,6 +258,16 @@ public void handlePersisted(PersistedNotification notification) {
             long excess = totalStored - retentionPolicyThreshold;
             availableBlocks.stream().sorted().limit(excess).forEach(this::delete);
         }
+        // @todo(1268) Not sure if we still would want to filter by notification provider priority.
+        //    In theory the new retention logic no longer supports that. We no longer delete the
+        //    range of the notification. More than that, if we have only this plugin that will fire
+        //    such notifications, effectively we will never cleanup. I think that should also be
+        //    changed. Another way to do this is to delete in the verification notification method.
+        //    In theory from there we get the new data and the idea of the policy is to be bound to
+        //    block count and delete only if new data arrives. Maybe we could drop the handle
+        //    persisted here all together? But we have to be careful because a big delete might
+        //    take a long while and we do not want to hang the notification thread too long cause
+        //    persistence relies on it (verification notification method). Am I missing something?
     }
 
     // ==== Action Methods =============================================================================================