fix(victauri-test): timestamp-based IPC checkpoints survive the log window cap - #64
Merged
Merged
Conversation
…indow cap
create_ipc_checkpoint snapshotted the IPC log LENGTH and ipc_calls_since
did skip(length) - but the server's log tools return a capped sliding
window of the NEWEST entries (default 100). On any app with more than
~100 logged IPC calls the checkpoint equals the window size and
calls_since is silently ALWAYS empty.
Found live on 4DA during the rmcp 3.1.2 verification: its dogfood
suite's ipc_integrity_healthy and parallel_ipc_burst canary assertions
failed ("calls since checkpoint: []") while a manual canary repro
proved capture itself worked - the client arithmetic was the bug.
Latent since the 0.7.10 log-capping change; unrelated to rmcp.
Fix: the checkpoint is now the newest entry timestamp (epoch ms);
calls_since filters by it over a 1000-entry read - immune to window
position. Signatures unchanged (usize). Entries without a timestamp are
included only for the zero checkpoint.
Verified: the two failing 4DA dogfood tests pass against live 4DA with
this client (153/165 suite, all remaining failures 4DA-side drift);
two new mock-server regression tests pin the sliding-window scenario;
existing ipc_checkpoint_tracks_new_calls stays green; fmt/clippy/full
workspace tests clean.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01KSa8Fdy8xgexFYYx47DkAg
runyourempire
added a commit
that referenced
this pull request
Aug 11, 2026
…ive-verified (#65) Version bump 0.8.7 -> 0.8.8 across the workspace (bump script + manual: server.json, which the script does not cover and which was still at 0.8.6 - missed by the 0.8.7 release; vscode extension to 0.8.8). Release-prep adversarial sweep applied on top of the merged train (#62 rmcp 3.1.2, #63 tauri 2.11.5 lock, #64 checkpoint fix): - Fixed stale session-era claims in faq/testing/architecture/ getting-started docs, victauri-test rustdoc, and the CLI init template (the transport is stateless by default; 2026-07-28 removes sessions). - Fixed two stale "31 tools" counts (plugin README, agent-session example) and the "subscribable resources" claim (subscribe was never advertised and is legacy-only); documented the new SEP-2549 cache hints; refreshed stale sample versions. - build_app_stateful doc notes 2026-07-28 clients are always sessionless. Adversarial verification before this release: zero stale rmcp-1.5 API refs in code; tools_fallback.json verified at 35 entries; JS log timestamps verified integer Date.now() everywhere (checkpoint-fix soundness); privacy config verified init-only (list-TTL soundness); REAL stdio bridge e2e vs the new server for BOTH the shipped 0.8.6 CLI and this tree's CLI (initialize/tools-list/tool-calls + identity selection across two live apps) - all pass. Gate: fmt clean; clippy --all-targets 0 warnings (default, no-default, release); full workspace tests 0 failures; cargo doc -D warnings clean; cargo semver-checks: no semver update required (x3 crates); cargo package OK for all leaf crates (dependents blocked only on the not-yet-published 0.8.8 core - expected pre-publish ordering). Claude-Session: https://claude.ai/code/session_01KSa8Fdy8xgexFYYx47DkAg Co-authored-by: audit <[email protected]> Co-authored-by: Claude Fable 5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Found live on 4DA during the rmcp 3.1.2 verification.
create_ipc_checkpoint()snapshotted the IPC log length andipc_calls_since()didskip(length)— but the server's log tools return a capped sliding window of the newest entries (default 100, since 0.7.10). On any app with >~100 logged IPC calls, checkpoint == window size andcalls_sinceis silently always empty.Live evidence chain: 4DA's dogfood suite failed
ipc_integrity_healthy+parallel_ipc_burst("calls since checkpoint: []"); a manual REST canary (invokeget_settings→ count entries 14→15) proved capture works — the client arithmetic was the bug. Latent since 0.7.10; unrelated to rmcp 3.x.Fix
Checkpoint = newest entry
timestamp(epoch ms);calls_sincefilters by it over a 1000-entry read — immune to window position. Signatures unchanged (usize). Timestamp-less entries included only for the zero checkpoint.Verification
ipc_checkpoint_tracks_new_callsstays green under the new semantics; fmt/clippy/full workspace tests clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01KSa8Fdy8xgexFYYx47DkAg