Follow-ups from #5608: the dead getBucketById null-check has siblings, monotonic stats are gauges, Studio hides zeroes, CI is permanently red #5636

Summary

Four things surfaced while doing #5608 (PR #5611, merged as bf5137ce0) that were out of its scope. Only the first is a defect with user-visible consequences; the rest are observability and hygiene items that the same work made visible. Grouped into one issue because they were all found in one pass and none is big enough to stand alone.

• 1. The dead null-check that Follow-ups from #5596: surface the merge counters, pin the compressPage coupling, prune redundant poison calls #5608 item 4 fixed is a PATTERN, and at least one other instance costs a user a good error message.

  Follow-ups from #5596: surface the merge counters, pin the compressPage coupling, prune redundant poison calls #5608 established that LocalSchema.getBucketById(id) (single-arg, LocalSchema.java:444) raises SchemaException in exactly the cases a caller would test for null - both an out-of-range id and a component that is not a bucket - so every if (bucket == null) written after it is unreachable. The two-arg getBucketById(id, false) (:448) is the form that returns the null those branches were written against. Two more sites do the same thing:

  • BinarySerializer.readExternalValue (BinarySerializer.java:1183-1191) - the one that actually costs something. The dead branch holds a deliberately written, user-actionable SerializationException: "If the bucket was tiered to a secondary path, set 'arcadedb.externalPropertyBucketPath' to the same value used at creation time and reopen the database." That message is unreachable. A user who hits precisely the scenario its own comment describes - an EXTERNAL property bucket tiered via arcadedb.externalPropertyBucketPath, then reopened with that config unset - gets a bare Bucket with id 'N' was not found and none of the guidance someone wrote for exactly this moment. This is the hardest case in the file to diagnose from the outside, which is presumably why the message exists.

  • TruncateBucketStatement (TruncateBucketStatement.java:63-66) - cosmetic. The branch is dead too, but the enclosing catch (Exception) rewraps into the same CommandExecutionException, so the only damage is a doubled message (Bucket not found: Bucket with id '9999' was not found). Listing it for completeness, not as a reason to act.

  While checking those: BinarySerializer.finalizeExternalWrite (:1155) dereferences the bucket with no null check at all. That is not an NPE risk - the single-arg form throws first - but it means the WRITE path of the same feature raises a bare SchemaException where the READ path at least tried to explain itself. Worth making the pair consistent.

  Fix: two-arg lookup at :1183 and :63, which is the exact one-line change Follow-ups from #5596: surface the merge counters, pin the compressPage coupling, prune redundant poison calls #5608 made. Better than fixing the call sites one at a time as they are found: the one-arg form's javadoc says nothing about throwing, and its name reads like a plain accessor - that API shape is what keeps inviting the mistake. Documenting the throw on getBucketById(int), and grepping the remaining call sites once, would close the pattern rather than the instance.

• 2. Every monotonic engine counter is exposed as a Micrometer Gauge, not a FunctionCounter.

  Raised during the fix(engine) #5608: the merge counters reach the operator, and the compression a rebase owes its page is structural #5611 review and deliberately not acted on there, because changing only the three counters that PR added would have made them inconsistent with the ten already in EngineMetricsBinder. It affects all of them: page.cache.hits, page.cache.misses, pages.read, pages.written, wal.bytes.written, mvcc.conflicts, tx.write, tx.read, tx.rollbacks, queries, commands, and now page.merges.*. Each is a never-decreasing total registered through Gauge.builder.

  Consequence in Prometheus: no _total suffix and no type hint that rate()/increase() are the correct functions over these series. A dashboard author reading arcadedb_engine_mvcc_conflicts as a gauge sees a line that only goes up and learns nothing.

  This is a deliberate, breaking decision (the metric names change), which is why it wants its own issue rather than being smuggled into a fix: converting to FunctionCounter renames the exported series, so it needs a release-note entry and probably a deprecation window.

• 3. Studio renders a zero-valued profiler stat as absent rather than as zero.

  studio-server.js, displayMetrics, profiler-details table: the value chain is else if (entry.count != null && entry.count != 0) and otherwise continue. A counter sitting at 0 is therefore skipped entirely, so the operator cannot tell "this is zero" from "this is not reported". For a health signal that is backwards - zero is the good state and its absence is the ambiguous one. The same != 0 guard is applied to space as well.

  (The three counters added in Follow-ups from #5596: surface the merge counters, pin the compressPage coupling, prune redundant poison calls #5608 dodge this only because they went into the rate-tracked table, which has no such guard. Everything else in the details table is affected.)

• 4. Three CI checks are red on every commit, which trains reviewers to ignore red.

  Observed across fix(engine) #5608: the merge counters reach the operator, and the compression a rebase owes its page is structural #5611 and confirmed on main's own commits:

  • Meterian client scan fails on every main commit: Unable to generate lockfile in folder /github/workspace/bindings/python -> python: python dependencies generation failed -> Failed checks: [security]. The Java scan itself passes; the Python bindings kill the run.
  • Dependency Review fails on a config error, not on a dependency: Error parsing package-url: package-url must start with "pkg:" on allow_dependencies_licenses. The workflow passes license identifiers (MIT, Apache-2.0, ...) to allow-dependencies-licenses, which expects package-URLs; the license allow-list belongs in allow-licenses. Note .github/dependency-review-config.yml also declares a licensing.allow list, so the two may be fighting each other.

  Neither has anything to do with the PRs they block. A PR author cannot distinguish "my change broke something" from "this is always red", which is the actual cost.

  For the record, a correction to something I reported mid-review: I initially attributed a third failure (Frontend Security Audit) to a vulnerable Bootstrap 4.x pin. That was wrong - studio/package.json pins ^5.3.8. The failure came from an older version of the check script, which has since been rewritten on main to parse the major version properly and no longer misfires.

Context: #5596, #5608, PR #5611 (bf5137ce0).