chore(deps): bump logos from 0.14.4 to 0.16.1#79
Merged
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
force-pushed
the
dependabot/cargo/logos-0.16.1
branch
from
April 15, 2026 06:24
8b344cf to
bf384aa
Compare
Contributor
Author
|
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
2 similar comments
Contributor
Author
|
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Contributor
Author
|
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
dependabot
Bot
force-pushed
the
dependabot/cargo/logos-0.16.1
branch
from
April 22, 2026 12:54
bf384aa to
e9dd224
Compare
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
dependabot
Bot
force-pushed
the
dependabot/cargo/logos-0.16.1
branch
from
April 23, 2026 06:28
e9dd224 to
e82a6a8
Compare
pilotspacex-byte
added
the
skip-changelog
Contributor
|
@dependabot rebase |
Bumps [logos](https://github.com/maciejhirsz/logos) from 0.14.4 to 0.16.1. - [Release notes](https://github.com/maciejhirsz/logos/releases) - [Changelog](https://github.com/maciejhirsz/logos/blob/master/RELEASE-PROCESS.md) - [Commits](maciejhirsz/logos@v0.14.4...v0.16.1) --- updated-dependencies: - dependency-name: logos dependency-version: 0.16.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/cargo/logos-0.16.1
branch
from
June 10, 2026 13:53
e82a6a8 to
1a72c72
Compare
logos 0.16 removed three constructs the lexer used: - `#[logos(source = [u8])]` → `#[logos(utf8 = false)]` (same Source = [u8] byte-slice lexing, new attribute name). - `ignore(ascii_case)` → `ignore(case)` on all keyword tokens (Unicode case folding; identical behavior for the ASCII keywords). - Unbounded greedy repetitions now require an explicit opt-in: the line-comment pattern `//[^\n]*` gains `allow_greedy = true` (it is bounded by the newline class, so the lint is a false positive here). All 442 cypher/graph unit tests pass; clippy and fmt clean. author: Tin Dang
TinDang97
added a commit
that referenced
this pull request
Jul 16, 2026
…task #56) The G2 acceptance run (4 shards, --maxmemory 256MB, 2.6GB dataset, disk-offload enabled) reported INFO used_memory at 406-762MB against the 256MB cap, and worse after a kill-9 restart. A 2-shard/8MB-cap/40k-key macOS repro (tests/used_memory_offload_truthful.rs) instrumented at load, steady state, and post-restart isolated three independent bugs: 1. used_memory was literally process RSS (src/command/connection.rs), not the logical ledger --maxmemory eviction actually gates on. RSS carries allocator overhead, mmap'd cold-read page-cache, the Lua script cache, and the replication backlog -- none of which eviction charges against the cap. INFO now reports the same KV(+ColdIndex)+vector+text+graph used-term ShardDatabases::recompute_elastic_budget already gates on (admin::metrics_setup::logical_used_memory_bytes); used_memory_rss / used_memory_peak still expose the true OS footprint, a new moon_used_memory_bytes Prometheus gauge mirrors the ledger, and MEMORY DOCTOR gained a "gated vs RSS vs outside-the-cap" section. 2. Restart double-loaded every spilled String key into hot RAM (src/persistence/recovery.rs): v3 recovery Phase 3 re-inserted each previously-spilled String entry directly into the hot DashTable (#79-04, predating cold read-through) AND rebuilt a ColdIndex stub for the same key (#80-02) -- nobody removed the first loop when the second, correct mechanism landed. Every value type now recovers as a cold-index-only stub; the first GET lazily promotes and only then charges used_memory, via the same path ordinary cold read-through uses. 3. AOF replay re-hydrated already-cold keys back into hot RAM on every restart (src/main.rs, src/storage/db.rs): fixing #2 exposed this second, independent path -- only surfaces with --appendonly yes AND disk-offload both active. An evicted-and-spilled key gets no AOF DEL record (record_reason_del never fires for a spilled entry), so AOF replay blindly reapplies the key's original SET into hot RAM with zero cold-tier awareness, transiently re-inflating used_memory to ~6x steady state after every restart (self-healing over several eviction ticks, slower the larger the offloaded dataset -- the "got WORSE after restart" symptom). Database::demote_replayed_cold_shadows reconciles this right after AOF replay finishes, before the server accepts connections: any key still present in the (already crash-consistent) ColdIndex at that point is provably redundant with what replay just wrote hot for it, so the redundant hot copy is dropped. Red/green: tests/used_memory_offload_truthful.rs drives all three mechanisms end-to-end (spill past maxmemory, confirm real disk spill, SIGKILL, restart) and asserts used_memory stays within 1.75x maxmemory at steady state AND immediately post-restart. Before (pre-fix baseline binary): steady_max_used=39,632,896 (4.7x the 8MB cap; used == rss, confirming the RSS-as-used_memory bug) -- test fails at the steady-state assertion. After (all three fixes): steady_max_used=8,388,410 (~1.0x cap), post_restart_max_used=8,388,410 (identical to steady state, no post-restart transient at all) -- test passes both assertions, reproducibly across repeated runs. Scope: confined to accounting/reporting (charging, uncharging, INFO/ metrics surfaces, restart re-charge paths) per the task boundary -- spill file format/batching is owned by a separate concurrent effort and was not touched. Gates run on macOS (VM occupied by a concurrent crash-matrix run): - cargo fmt --check: clean - cargo clippy --tests -- -D warnings (default features): clean - cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings: clean - cargo test --lib (default features): 4331 passed, 0 failed, 1 ignored - cargo test --lib --no-default-features --features runtime-tokio,jemalloc storage::db::: 35 passed - cargo test --release --test used_memory_offload_truthful -- --ignored: pass (repeated) - cargo test --release --test crash_matrix_per_shard_aof: 3 passed - cargo test --release --test crash_recovery_cold_del_resurrection: 2 passed - cargo test --release --test crash_recovery_disk_offload_no_aof: 1 passed - cargo test --release --test crash_recovery_orphan_sweep_readiness: 1 passed - cargo test --release --test memory_doctor_response: 1 passed - cargo test --test aof_multidb_kill9: 4 passed VM-scale validation still needed: re-run the original G2 acceptance scenario (4 shards, 2.6GB dataset, --maxmemory 256MB) on moon-dev once free, to confirm used_memory stays truthful at that scale and that the post-restart AOF-replay-demotion pass completes promptly on a much larger cold index / AOF incr log than this repro's 40k keys. author: Tin Dang <tindang.ht97@gmail.com>
TinDang97
added a commit
that referenced
this pull request
Jul 16, 2026
…task #56) The G2 acceptance run (4 shards, --maxmemory 256MB, 2.6GB dataset, disk-offload enabled) reported INFO used_memory at 406-762MB against the 256MB cap, and worse after a kill-9 restart. A 2-shard/8MB-cap/40k-key macOS repro (tests/used_memory_offload_truthful.rs) instrumented at load, steady state, and post-restart isolated three independent bugs: 1. used_memory was literally process RSS (src/command/connection.rs), not the logical ledger --maxmemory eviction actually gates on. RSS carries allocator overhead, mmap'd cold-read page-cache, the Lua script cache, and the replication backlog -- none of which eviction charges against the cap. INFO now reports the same KV(+ColdIndex)+vector+text+graph used-term ShardDatabases::recompute_elastic_budget already gates on (admin::metrics_setup::logical_used_memory_bytes); used_memory_rss / used_memory_peak still expose the true OS footprint, a new moon_used_memory_bytes Prometheus gauge mirrors the ledger, and MEMORY DOCTOR gained a "gated vs RSS vs outside-the-cap" section. 2. Restart double-loaded every spilled String key into hot RAM (src/persistence/recovery.rs): v3 recovery Phase 3 re-inserted each previously-spilled String entry directly into the hot DashTable (#79-04, predating cold read-through) AND rebuilt a ColdIndex stub for the same key (#80-02) -- nobody removed the first loop when the second, correct mechanism landed. Every value type now recovers as a cold-index-only stub; the first GET lazily promotes and only then charges used_memory, via the same path ordinary cold read-through uses. 3. AOF replay re-hydrated already-cold keys back into hot RAM on every restart (src/main.rs, src/storage/db.rs): fixing #2 exposed this second, independent path -- only surfaces with --appendonly yes AND disk-offload both active. An evicted-and-spilled key gets no AOF DEL record (record_reason_del never fires for a spilled entry), so AOF replay blindly reapplies the key's original SET into hot RAM with zero cold-tier awareness, transiently re-inflating used_memory to ~6x steady state after every restart (self-healing over several eviction ticks, slower the larger the offloaded dataset -- the "got WORSE after restart" symptom). Database::demote_replayed_cold_shadows reconciles this right after AOF replay finishes, before the server accepts connections: any key still present in the (already crash-consistent) ColdIndex at that point is provably redundant with what replay just wrote hot for it, so the redundant hot copy is dropped. Red/green: tests/used_memory_offload_truthful.rs drives all three mechanisms end-to-end (spill past maxmemory, confirm real disk spill, SIGKILL, restart) and asserts used_memory stays within 1.75x maxmemory at steady state AND immediately post-restart. Before (pre-fix baseline binary): steady_max_used=39,632,896 (4.7x the 8MB cap; used == rss, confirming the RSS-as-used_memory bug) -- test fails at the steady-state assertion. After (all three fixes): steady_max_used=8,388,410 (~1.0x cap), post_restart_max_used=8,388,410 (identical to steady state, no post-restart transient at all) -- test passes both assertions, reproducibly across repeated runs. Scope: confined to accounting/reporting (charging, uncharging, INFO/ metrics surfaces, restart re-charge paths) per the task boundary -- spill file format/batching is owned by a separate concurrent effort and was not touched. Gates run on macOS (VM occupied by a concurrent crash-matrix run): - cargo fmt --check: clean - cargo clippy --tests -- -D warnings (default features): clean - cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings: clean - cargo test --lib (default features): 4331 passed, 0 failed, 1 ignored - cargo test --lib --no-default-features --features runtime-tokio,jemalloc storage::db::: 35 passed - cargo test --release --test used_memory_offload_truthful -- --ignored: pass (repeated) - cargo test --release --test crash_matrix_per_shard_aof: 3 passed - cargo test --release --test crash_recovery_cold_del_resurrection: 2 passed - cargo test --release --test crash_recovery_disk_offload_no_aof: 1 passed - cargo test --release --test crash_recovery_orphan_sweep_readiness: 1 passed - cargo test --release --test memory_doctor_response: 1 passed - cargo test --test aof_multidb_kill9: 4 passed VM-scale validation still needed: re-run the original G2 acceptance scenario (4 shards, 2.6GB dataset, --maxmemory 256MB) on moon-dev once free, to confirm used_memory stays truthful at that scale and that the post-restart AOF-replay-demotion pass completes promptly on a much larger cold index / AOF incr log than this repro's 40k keys. author: Tin Dang <tindang.ht97@gmail.com>
pilotspacex-byte
added a commit
that referenced
this pull request
Jul 16, 2026
…edger, stub-only recovery, replay demote (task #56) (#349) * fix(storage): make used_memory truthful under disk-offload restarts (task #56) The G2 acceptance run (4 shards, --maxmemory 256MB, 2.6GB dataset, disk-offload enabled) reported INFO used_memory at 406-762MB against the 256MB cap, and worse after a kill-9 restart. A 2-shard/8MB-cap/40k-key macOS repro (tests/used_memory_offload_truthful.rs) instrumented at load, steady state, and post-restart isolated three independent bugs: 1. used_memory was literally process RSS (src/command/connection.rs), not the logical ledger --maxmemory eviction actually gates on. RSS carries allocator overhead, mmap'd cold-read page-cache, the Lua script cache, and the replication backlog -- none of which eviction charges against the cap. INFO now reports the same KV(+ColdIndex)+vector+text+graph used-term ShardDatabases::recompute_elastic_budget already gates on (admin::metrics_setup::logical_used_memory_bytes); used_memory_rss / used_memory_peak still expose the true OS footprint, a new moon_used_memory_bytes Prometheus gauge mirrors the ledger, and MEMORY DOCTOR gained a "gated vs RSS vs outside-the-cap" section. 2. Restart double-loaded every spilled String key into hot RAM (src/persistence/recovery.rs): v3 recovery Phase 3 re-inserted each previously-spilled String entry directly into the hot DashTable (#79-04, predating cold read-through) AND rebuilt a ColdIndex stub for the same key (#80-02) -- nobody removed the first loop when the second, correct mechanism landed. Every value type now recovers as a cold-index-only stub; the first GET lazily promotes and only then charges used_memory, via the same path ordinary cold read-through uses. 3. AOF replay re-hydrated already-cold keys back into hot RAM on every restart (src/main.rs, src/storage/db.rs): fixing #2 exposed this second, independent path -- only surfaces with --appendonly yes AND disk-offload both active. An evicted-and-spilled key gets no AOF DEL record (record_reason_del never fires for a spilled entry), so AOF replay blindly reapplies the key's original SET into hot RAM with zero cold-tier awareness, transiently re-inflating used_memory to ~6x steady state after every restart (self-healing over several eviction ticks, slower the larger the offloaded dataset -- the "got WORSE after restart" symptom). Database::demote_replayed_cold_shadows reconciles this right after AOF replay finishes, before the server accepts connections: any key still present in the (already crash-consistent) ColdIndex at that point is provably redundant with what replay just wrote hot for it, so the redundant hot copy is dropped. Red/green: tests/used_memory_offload_truthful.rs drives all three mechanisms end-to-end (spill past maxmemory, confirm real disk spill, SIGKILL, restart) and asserts used_memory stays within 1.75x maxmemory at steady state AND immediately post-restart. Before (pre-fix baseline binary): steady_max_used=39,632,896 (4.7x the 8MB cap; used == rss, confirming the RSS-as-used_memory bug) -- test fails at the steady-state assertion. After (all three fixes): steady_max_used=8,388,410 (~1.0x cap), post_restart_max_used=8,388,410 (identical to steady state, no post-restart transient at all) -- test passes both assertions, reproducibly across repeated runs. Scope: confined to accounting/reporting (charging, uncharging, INFO/ metrics surfaces, restart re-charge paths) per the task boundary -- spill file format/batching is owned by a separate concurrent effort and was not touched. Gates run on macOS (VM occupied by a concurrent crash-matrix run): - cargo fmt --check: clean - cargo clippy --tests -- -D warnings (default features): clean - cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings: clean - cargo test --lib (default features): 4331 passed, 0 failed, 1 ignored - cargo test --lib --no-default-features --features runtime-tokio,jemalloc storage::db::: 35 passed - cargo test --release --test used_memory_offload_truthful -- --ignored: pass (repeated) - cargo test --release --test crash_matrix_per_shard_aof: 3 passed - cargo test --release --test crash_recovery_cold_del_resurrection: 2 passed - cargo test --release --test crash_recovery_disk_offload_no_aof: 1 passed - cargo test --release --test crash_recovery_orphan_sweep_readiness: 1 passed - cargo test --release --test memory_doctor_response: 1 passed - cargo test --test aof_multidb_kill9: 4 passed VM-scale validation still needed: re-run the original G2 acceptance scenario (4 shards, 2.6GB dataset, --maxmemory 256MB) on moon-dev once free, to confirm used_memory stays truthful at that scale and that the post-restart AOF-replay-demotion pass completes promptly on a much larger cold index / AOF incr log than this repro's 40k keys. author: Tin Dang <tindang.ht97@gmail.com> * fix(storage): close three adversarial-review DO-NOT-SHIP gaps on used_memory offload fix Adversarial review of fix/t56-used-memory-offload flagged three gaps before this branch could ship: a critical stale-data resurrection bug, a recovery path where the new demotion logic was never invoked, and an undocumented used_memory parity gap. All three are fixed here. - CRITICAL: Database::set() (src/storage/db.rs) now clears a key's ColdIndex shadow the instant a second write to that key is observed (InsertOrUpdate::Updated). Without this, a key spilled at v1 and then live-overwritten to v2 (no re-eviction before a crash) would have its hot v2 wrongly dropped by demote_replayed_cold_shadows on restart, resurrecting stale v1. Provably safe because AOF replay always starts from an empty DashTable, so a key's first replayed write is always Inserted (left alone) and any later write during that replay can only be Updated if the AOF recorded a write after the one that got spilled. - HIGH: recover_shard_v3_pitr's Phase 4b appendonly.aof fallback (src/persistence/recovery.rs) is the ONLY KV replay path under runtime-tokio + --shards 1 (no AofManifest exists there), and it never called demote_replayed_cold_shadows. It now does, closing the gap for that runtime/shard combination. - MEDIUM: logical_used_memory_bytes() (src/admin/metrics_setup.rs) and the moon_used_memory_bytes gauge now include the Lua script cache and replication backlog, matching real Redis's used_memory semantics (allocator-attributed, not eviction-reclaimable). Both terms were already tracked as separate moon_memory_bytes{kind=...} gauges, so this costs no new instrumentation. The actual --maxmemory eviction gate (ShardDatabases::recompute_elastic_budget) is unchanged and narrower. MEMORY DOCTOR (src/command/server_admin.rs) and docs/guides/monitoring.md now show three distinct figures: elastic budget, used_memory (reported), and RSS. New tests (all RED before their respective fix, GREEN after): - storage::db::tests::test_second_write_invalidates_cold_shadow (unit) - tests/cold_shadow_overwrite_resurrection.rs (overwritten_cold_key_returns_new_value_after_crash) - tests/cold_shadow_single_shard_tokio.rs (single_shard_overwritten_cold_key_returns_new_value_after_crash, run against a runtime-tokio+jemalloc binary; uses SETEX per the monoio-write-gate/inline-SET dispatch gotcha) Verified: cargo fmt --check, cargo clippy --tests -- -D warnings (default features), cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings, cargo test --lib (4332 passed), plus the full existing disk-offload/crash-recovery integration suite (used_memory_offload_truthful, crash_recovery_cold_del_resurrection, crash_matrix_per_shard_aof, memory_doctor_response, aof_multidb_kill9) — all green with no regressions. author: Tin Dang --------- Co-authored-by: Tin Dang <tindang.ht97@gmail.com>
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
2 participants
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.
Bumps logos from 0.14.4 to 0.16.1.
Release notes
Sourced from logos's releases.
... (truncated)
Commits
8c77ac0Merge pull request #538 from maciejhirsz/release-0.16.16954649chore(version): release v0.16.1331eef6Merge pull request #536 from ascopes/patch-1eacbd43Fix typo in logos.md subpatterns sectionfe0d806Merge pull request #534 from robot-rover/master14b4cadfixup! Fix skip allow_greedy2ebbef8Cleanup massive array literal in parser.rs164579dFix skip allow_greedy2906820Merge pull request #533 from tisonkun/coalesce-ci1ff0091ci: coalesce styles