matrixarkai/TemporalStore

tools/validate_page_block_metrics_conformance.py exits 1 on main and says so clearly — the runner it validates against has never existed in this repository. No workflow runs it, so nothing has noticed. Reproduce it cd tools && python3 validate_page_block_metrics_conformance.py; echo "rc=$?" rc=1, and its own message states the problem better than a summary could: cannot run: run_matrixark_rust_scale_report.py is absent from this repository, and it is the runner this validates the published contract against. Five files still refer to it and no version of this repository has contained it. Either it belongs here, or this validator does not. That last sentence is the whole issue, and the validator author left it deliberately. What to do Establish which of the two it is, and say so in the pull request: The runner belongs here and was never brought over. Then this validator is correct and blocked, and the right change is probably not yours to make — say what you found, name the five f

tools/validate_storage_proxy_client_conformance_coverage.py exits 1 on main, and no workflow runs it, so nothing has noticed. One of its assertions names a Rust module that does not exist. Reproduce it cd tools && python3 validate_storage_proxy_client_conformance_coverage.py; echo "rc=$?" rc=1, and it prints a list headed missing Rust shared-corpus test markers:. The assertion that cannot pass validate_storage_proxy_client_conformance_coverage.py:96 if "mod slot_store;" not in ENGINE.read_text(): validate_storage_proxy_client_conformance_coverage.py:97 fail("engine.rs must declare slot_store runtime module") git grep -c 'mod slot_store' -- crates/ # 0 git grep -c 'mod block_store' -- crates/ # 1 The second command is the control: the module-declaration shape the validator is looking for does exist in the tree, under a different name. slot_store appears nowhere. What to work out, and please say which in the pull request The module was renamed and this assertion was left

crates/temporalstore-rust/src/wal.rs calls one thing by two names. A rolled write-ahead-log file is a segment in most of the tree and a piece in three helpers, and one function calls the other, so the two names are provably the same unit rather than two related ideas. What is there wal.rs:3191 fn wal_segment_paths(root: &Path, shard_id: ShardId) -> Vec<PathBuf> wal.rs:3203 struct WalPiece wal.rs:3215 fn wal_segment_pieces(root: &Path, shard_id: ShardId) -> Vec<WalPiece> wal_segment_paths calls wal_segment_pieces and discards everything but the paths. So a WalPiece is a WAL segment, and the name piece adds nothing a reader can use. Counts, so the size is clear before you start: git grep -c WalPiece -- crates/ git grep -c wal_segment_pieces -- crates/ git grep -c wal_segment_paths -- crates/ At the time of writing: WalPiece 4, wal_segment_pieces 4, wal_segment_paths 33. The piece spelling is confined to the smaller two. What to change Rename the piece spelling to segment — WalPi

tools/temporalstore-prometheus/vars-exporter/test_vars_to_prom.py asserts on a metric the engine does not emit. The test passes, because it checks the exporter's mapping rather than whether anything produces the input. Reproduce it git grep -n temporalstore_server_partition_page_store_persistent_read_qps -- tools/ git grep -n temporalstore_server_partition_page_store_persistent_read_qps -- crates/ git grep -n partition_page_store_persistent_read_qps -- crates/ The first finds one line, test_vars_to_prom.py:64. The second and third find nothing — neither the Prometheus name nor the /vars source key it would be built from exists anywhere in the engine. For contrast, a metric that really is emitted: git grep -c temporalstore_storage_bucket_bytes -- crates/ What is actually wrong The exporter turns /vars keys into Prometheus names. A test naming a key the server never publishes asserts on a mapping that can never fire in production, so it cannot fail for a reason anyone cares about — a

engine/tests/range_free_bucket_id.rs:111 carries use super::*; which the compiler reports as unused, because the module imports everything it needs explicitly: use super::*; // <- unused use crate::engine::hashing::{block_routing_bucket, routing_bucket_count, stable_object_hash}; use crate::block_store::BlockAddress; use crate::engine::state::{BlockLookupRef, BucketNode}; use std::collections::BTreeMap; Introduced by #1983. It was left in deliberately rather than removed before merge, so that the merged tree is byte-identical to the tree the single-threaded gate ran against — the module's seven tests were gated at adb88e4ae5f0e7081efe27a062577a85271d5bde and removing a line after that would have made the merged artifact differ from the gated one. It is also not worth removing blind. This repository has a recorded incident where an apparently-unused import was a re-export consumed as module.name, invisible to every import-based check,