fix(engine) #5636: read the WAL stat map once, and keep the PR-time Meterian signal

Round 2 review on #5640. Four of the five points applied, one declined with the reason recorded in the code.

1. collectDatabaseStats() called TransactionManager.getStats() twice per open database - once inside the fold
   for pagesWritten/bytesWritten and again for logFiles - and that call allocates a HashMap and walks the
   active WAL pool each time. Since the whole point of the refactor was to stop maintaining two copies of the
   loop, accumulateMonotonic now returns the map it read. logFiles cannot join the fold itself: it is a current
   count, not a total, so carrying it across a close would inflate it forever.

3. unregisteringTwiceFoldsTheCountersOnlyOnce asserted exact equality against a JVM-singleton counter. Today
   surefire runs forkCount=1/reuseForks=true so classes are sequential, but the assertion would go intermittent
   the day that changes. Bounded instead: a second fold would add at least this database's own QUERIES again.

4. The two new Schema methods are source-incompatible for a third-party implementor. Noted in the release notes.

5. Meterian keeps running on pull_request. continue-on-error already stops it failing the check, so dropping the
   PR trigger would have thrown away the per-PR SARIF diff for no gain: a newly introduced vulnerable dependency
   now still surfaces at PR time rather than only once it lands on main.

Point 2 (the scrape path has no per-database try/catch while the close path does) is declined, and why is now a
comment on collectDatabaseStats: skipping a database whose stat sources are mid-teardown would drop its
contribution from one snapshot and restore it on the next, which is a transient DIP - precisely the counter-reset
artifact this change exists to eliminate. Letting the read throw surfaces as a failed scrape, which Prometheus
handles by carrying the last value forward. A wrong number is worse than a missing one here.

Author: lvca

.github/workflows/meterian.yml

@@ -18,6 +18,10 @@ name: Meterian Scanner workflow
 on:
   push:
     branches: [main]
+  # PRs are still scanned. What changed is that the result cannot fail the check (continue-on-error below), so a
+  # newly introduced vulnerable dependency still surfaces its SARIF diff at PR time instead of only after it lands
+  # on main - the signal is kept, only the blocking red X is dropped.
+  pull_request:
   schedule:
     # Daily, so the alert set stays current between main commits.
     - cron: "17 4 * * *"

docs/release-26.8.1.md

@@ -945,6 +945,10 @@ The API shape is what kept inviting the mistake, so the pattern is closed rather
 exposes null-returning `getBucketByIdIfExists(int)` and `getBucketByNameIfExists(String)` - named after the
 `getFileByIdIfExists(int)` already on the interface - and the throwing forms document that they throw.
 
+Both in-tree implementors (`LocalSchema`, `RemoteSchema`) are updated. Note the two new interface methods are
+source-incompatible for anyone implementing `com.arcadedb.schema.Schema` outside the project: such an
+implementation needs the two methods added before it compiles against this release.
+
 ## Server and cluster status endpoints scope their per-database output to the caller
 
 The routes that enumerate the whole database registry rather than naming one database in the path now reduce

engine/src/main/java/com/arcadedb/Profiler.java

@@ -122,15 +122,23 @@ public synchronized void unregisterDatabase(final DatabaseInternal database) {
   /**
    * Sums the per-database counters of every open database on top of the retained baseline of the closed ones.
    * Shared by {@link #toJSON()} and {@link #dumpMetrics(PrintStream)} so the two cannot drift apart.
+   * <p>
+   * Deliberately NOT guarded per database, unlike the fold in {@link #unregisterDatabase}. Skipping a database whose
+   * stat sources are mid-teardown would drop its contribution from this one snapshot and restore it on the next -
+   * a transient DIP, which is exactly the counter-reset artifact this whole change exists to eliminate. Letting the
+   * read throw instead surfaces as a failed scrape, which Prometheus already handles by carrying the last value
+   * forward. A wrong number is worse than a missing one here.
    */
   private long[] collectDatabaseStats() {
     final long[] acc = new long[STATS_COUNT];
     System.arraycopy(retainedStats, 0, acc, 0, MONOTONIC_STATS);
 
     for (final DatabaseInternal db : databases) {
-      accumulateMonotonic(acc, db);
-
-      acc[STAT_WAL_TOTAL_FILES] += statOf(db.getTransactionManager().getStats(), "logFiles");
+      // The WAL map comes back from the fold rather than being re-read: TransactionManager.getStats() allocates a
+      // fresh HashMap and walks the active WAL pool on every call, and logFiles lives in the same map as the two
+      // monotonic WAL counters.
+      final Map<String, Object> walStats = accumulateMonotonic(acc, db);
+      acc[STAT_WAL_TOTAL_FILES] += statOf(walStats, "logFiles");
 
       final FileManager.FileManagerStats fStats = db.getFileManager().getStats();
       acc[STAT_OPEN_FILES] += fStats.totalOpenFiles;
@@ -146,15 +154,20 @@ private long[] collectDatabaseStats() {
    * Adds one database's monotonic counters into {@code acc}. Deliberately touches only the two stat sources that stay
    * readable after a close ({@link DatabaseInternal#getStats()} reads a plain counter holder, and
    * {@code TransactionManager.getStats()} guards a retired WAL pool), so {@link #unregisterDatabase} can reuse it.
+   *
+   * @return the WAL stat map it read, so a caller that also needs the instantaneous {@code logFiles} count out of it
+   *         does not pay for a second {@code TransactionManager.getStats()}. {@code logFiles} cannot join the fold
+   *         itself - it is a current count, not a total, so carrying it across a close would inflate it forever.
    */
-  private void accumulateMonotonic(final long[] acc, final DatabaseInternal db) {
+  private Map<String, Object> accumulateMonotonic(final long[] acc, final DatabaseInternal db) {
     final Map<String, Object> dbStats = db.getStats();
     for (int i = 0; i < DB_STAT_KEYS.length; i++)
       acc[i] += statOf(dbStats, DB_STAT_KEYS[i]);
 
     final Map<String, Object> walStats = db.getTransactionManager().getStats();
     acc[STAT_WAL_PAGES_WRITTEN] += statOf(walStats, "pagesWritten");
     acc[STAT_WAL_BYTES_WRITTEN] += statOf(walStats, "bytesWritten");
+    return walStats;
   }
 
   /**

engine/src/test/java/com/arcadedb/Issue5636ProfilerMonotonicTest.java

@@ -20,6 +20,7 @@
 
 import com.arcadedb.database.Database;
 import com.arcadedb.database.DatabaseFactory;
+import com.arcadedb.database.DatabaseInternal;
 import com.arcadedb.serializer.json.JSONObject;
 import com.arcadedb.utility.FileUtils;
 import org.junit.jupiter.api.AfterEach;
@@ -113,9 +114,12 @@ void unregisteringTwiceFoldsTheCountersOnlyOnce() {
       final long afterFirst = profilerCount("queries");
 
       // The database is already gone from the registry; a second unregister must be a no-op, not a second fold.
-      Profiler.INSTANCE.unregisterDatabase((com.arcadedb.database.DatabaseInternal) db);
+      Profiler.INSTANCE.unregisterDatabase((DatabaseInternal) db);
+      // Bounded rather than exact: a second fold would add at least this database's own QUERIES again, while
+      // anything else sharing the reused surefire fork can only add a few. Exact equality would go intermittent
+      // the day the suite runs test classes concurrently.
       assertThat(profilerCount("queries")).as("a repeated unregister must not fold the same counters in again")
-          .isEqualTo(afterFirst);
+          .isGreaterThanOrEqualTo(afterFirst).isLessThan(afterFirst + QUERIES);
       assertThat(afterFirst).isGreaterThanOrEqualTo(beforeClose);
     }