chore(deps): bump actions/checkout from 4 to 6#20
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 6. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v4...v6) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
2 tasks
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
pilotspacex-byte
pushed a commit
that referenced
this pull request
Jul 9, 2026
…uracy Two related vector-index correctness gaps from the production-hardening audit (Batch D). #20 Multi-vector-field deletion resurrection: tombstone_key_in_index only walked the default field's SegmentHolder (idx.segments); secondary VECTOR fields live in a separate idx.field_segments map that it never iterated. DEL/UNLINK/HDEL therefore left the vector alive in every non-default field, and a subsequent `FT.SEARCH idx '@field2:[...]'` resurrected the deleted document -- under a synthetic `vec:<id>` key, since the shared key_hash_to_key map was cleared unconditionally. Extracted a `tombstone_key_in_holder` helper and now apply it to the default field AND each field_segments entry. #28 FT.INFO num_docs miscount: - MutableSegment::len() returns entries.len() including tombstoned slots (mark_deleted_* only flips delete_lsn in place until compaction), so num_docs inflated by up to compact_threshold under DEL/HSET churn. Added MutableSegment::live_len() (excludes tombstones) and use it for num_docs / mutable_vectors in ft_info.rs (top-level + both per-field blocks). - DiskANN cold-tier segments (experimental, gated by MOON_VEC_COLD_TIER) were never summed even though cold docs ARE returned by FT.SEARCH. Added a `snap.cold` loop backed by a new DiskAnnSegment::num_docs(). Red/green tests: - vector::segment::mutable::tests::test_live_len_excludes_tombstoned - vector::store::bg_compact_tests::test_del_tombstones_secondary_vector_field Both runtimes compile + clippy -D warnings clean; 65 vector tests pass. Refs: tmp/PRODUCTION-HARDENING-AUDIT.md findings 20, 28 (Batch D). author: Tin Dang
This was referenced Jul 10, 2026
TinDang97
added a commit
that referenced
this pull request
Jul 11, 2026
…k epoch cancellation Attach-under-write stress testing of R2 (#283) surfaced three defects. All are fixed here before the PR merges; none shipped in a release. 1) REPLICAOF leaked the previous replica task (pre-existing, dominant signal). `REPLICAOF host port` spawned a fresh run_replica_task without stopping the old one, and `REPLICAOF NO ONE` only flipped the role: the old task kept streaming AND applying. Each NO-ONE → re-attach cycle stacked one more live applier — replica INCR counters ran ~25-35% ABOVE the master (reproduced at shards=1 and shards=4). Fix: process-global REPLICA_TASK_EPOCH ticket. StartReplication and PromoteToMaster bump the generation; a superseded task exits at the reconnect-loop top, before snapshot load, and before applying any parsed chunk — it can never mutate the keyspace again. 2) Snapshot-vs-live exactly-once now rests on an offset cut, not on FIFO placement. Two review rounds found opposite failure modes for placement schemes on the PSYNC connection's own shard: - queued snapshot leg (drain-time capture): a local write between push and drain was in the body AND live-sent behind the registration → double-apply (reproduced, +35%); - inline capture + queued registration: a same-cycle SPSC execute was neither in the body (applied after capture) nor live-sent (execute_batch direct-send runs before other_messages processes the registration) — with its bytes in the backlog and the offset advanced: silent loss + permanent replica ACK lag. Fix: every fan-out entry records cut = shard offset at body capture; every live record carries its per-shard end_offset; delivery requires end_offset > cut. Registration placement no longer matters, so ALL shards — including the PSYNC connection's own — use the same PrepareReplicaSync arm (the special-cased inline self-leg is gone). The cut/end_offset axis is the PER-SHARD counter, never the master offset (seed_master_offset diverges the two after AOF recovery). 3) Same-key wire ordering. SPSC-dispatched writes sent to replicas directly from the execute arm while local handler writes deferred through the self queue — a later-offset write could reach the wire before an earlier-offset same-key write, replaying out of the master's serialization order (analysis finding; not reproduced in ~10 black-box attempts). ALL live sends now flow through the self-queue ReplicaLiveFanout arm: per-shard wire order == FIFO order == offset order by construction. Tests (red/green: 1 and 2 reproduced red before their fixes): - tests/replication_multishard.rs +3: attach_under_write_no_double_apply (4-shard, 5x detach/re-attach under 4-writer pipelined INCR load, exact per-counter parity), singleshard_master_attach_under_write_control (same at shards=1 — the discriminating control that proved the task leak pre-existing), same_key_write_order_parity (12 conns APPEND-race 32 shared keys through both write paths; replica must byte-equal master). - Full regression: multishard 9/9, streaming 7/7, hardening 5/5, graph 5/5, aof_multidb_kill9 4/4, lib 4115 (monoio) + 3316 (tokio), clippy -D warnings both matrices, fmt — macOS and Linux VM. Mechanical: ShardMessage::RegisterReplica boxed (RegisterReplicaPayload; the extra offset fields pushed it past the 64-byte cap), ReplicaFanout tuple → struct with cut, increment_shard_offset returns the per-shard post-advance offset. Test-harness hardening surfaced by the Linux VM sweep (task #18 class): - replication_hardening now honors MOON_BIN (hardcoded ./target/release/moon exec'd the wrong-platform binary on the shared macOS/Linux checkout — all 5 tests failed to connect on the VM); - aof_multidb_kill9 wait_ready treats a connection RESET during moon's bootstrap→per-shard SO_REUSEPORT listener handover as "not ready yet" instead of panicking (3/4 VM failures, reproduced with main's binary too — environment-timing flake, not a code regression). Refs: task #20, task #36, PR #283 author: Tin Dang <tindang.ht97@gmail.com>
TinDang97
added a commit
that referenced
this pull request
Jul 11, 2026
… failure (review) CodeRabbit round on PR #283: - PrepareReplicaSync reply collection is now bounded (30s timeout per leg): a wedged shard can no longer park the PSYNC task — and the fan-out registrations it holds — forever. On expiry the sync aborts with explicit unregister everywhere; the replica reconnects and retries. - Socket-write failures during the +FULLRESYNC/RDB transfer also unregister on every shard instead of leaving the entries to the passive next-write Disconnected prune. - docs/guides/clustering.md quotes the full tokio PSYNC error text. - CHANGELOG documents the 16K pre-RDB live-buffer limitation (overflow during a very large snapshot under sustained writes KICKS the replica loudly into a retry — never silent divergence). Verified: multishard 9/9, clippy -D warnings, fmt. Refs: task #20, PR #283 author: Tin Dang <tindang.ht97@gmail.com>
pilotspacex-byte
added a commit
that referenced
this pull request
Jul 11, 2026
…ord SELECT framing (#283) * feat(replication): R2 multi-shard master PSYNC — merged RDB + per-record SELECT framing Masters running --shards N now serve full replication to a single-shard replica (task #20, RFC 1B). Previously PSYNC on a multi-shard master was rejected outright. Design: - ShardMessage::PrepareReplicaSync fans to every shard (self queue for the accepting shard, SPSC mesh + notifier for the rest). Each shard's arm serializes its keyspace slice to an RDB BODY, captures its shard offset, and registers the replica's live channel in ONE synchronous stretch on its own thread — per shard there is no window between "in the snapshot" and "streamed live", so no backlog catch-up leg exists and non-idempotent commands cannot double-apply. - The PSYNC task stitches bodies into ONE valid Redis-format RDB (redis_rdb::write_rdb_merged) and replies `+FULLRESYNC <replid> <sum of shard offsets>` + one $<len> bulk — the replica's existing R0 loader is unchanged. Index defs ride once; graph content is sharded so the snapshot carries one moon-graph-store aux entry PER shard, and the replica imports all of them (install_graph_store_many / read_moon_aux_all). - Merged-wire db context: N shard threads feed one replica socket, so per-shard SELECT tracking cannot work. On multi-shard masters every db-scoped record is fused with its own `SELECT <db>` prefix as ONE record (one channel send, one backlog append pair, one offset advance) in both the cross-shard path (wal_append_and_fanout) and the local leg (record_local_write_db) — no interleave can split a SELECT from the write it frames. Gated on the replica-attach hint; single-shard masters keep the emit-on-change tracking. - Partial resync degrades to full: a single scalar offset cannot map back onto N per-shard backlogs. - R1 pieces carry over unchanged: overflow-kick (shared kicked flag across all N fan-out entries), REPLCONF ACK reader, WAIT (summed snapshot offset keeps total_offset - base == bytes-on-wire, so ACK math stays exact). Verification (red/green): - NEW tests/replication_multishard.rs — 6 e2e over real processes, written first and failing on main: 2/4/8-shard full resync + live convergence with INCR exactness, interleaved multi-db writers (5k keys x 2 dbs, leak asserts both directions), per-shard graph snapshot import, raw-handshake partial->full degradation with merged-RDB REDIS-magic assert. - NEW unit merged_multishard_rdb_round_trip (repeated SELECTDB sections + repeated graph aux entries load as one keyspace, CRC valid). - Regression: replication_streaming 7/7, replication_hardening 3/3, replication_graph 5/5, aof_multidb_kill9 4/4, lib 4115 (monoio) + 3316 (tokio), clippy -D warnings on both matrices, fmt clean. author: Tin Dang <tindang.ht97@gmail.com> * docs(replication): document self-queue-first drain dependency in PrepareReplicaSync arm author: Tin Dang <tindang.ht97@gmail.com> * feat(replication): R3 — tokio PSYNC clear error + topology docs refresh RFC v0.2-R3 (2A + 4B), riding the R2 PR: - A runtime-tokio master now answers PSYNC with `-ERR PSYNC requires runtime-monoio on the master (this build runs runtime-tokio)` instead of falling through to generic dispatch — an attaching replica's log states WHY the sync failed. Wired in both tokio paths (handler_sharded intercept + handler_single inline arm) and verified live against real tokio binaries at shards=1 and shards=2. - Docs refreshed for the R2 topology: - docs/guides/clustering.md: v0.1.x "master must run --shards 1" warning replaced with the v0.7 deployment shape (any-N master / --shards 1 replicas, merged-RDB semantics, partial->full at N>1, WS/MQ plane caveat). - README.md: replication bullets updated (also fixes the stale claim that replicas could run --shards N — the replica task refuses N != 1). - docs/PRODUCTION-CONTRACT.md: REPL-MULTISHARD-01 and WAIT-01 flipped to done with R2/R1 evidence. - CHANGELOG [Unreleased] amended accordingly. author: Tin Dang <tindang.ht97@gmail.com> * fix(replication): exactly-once live fanout (offset cut) + replica-task epoch cancellation Attach-under-write stress testing of R2 (#283) surfaced three defects. All are fixed here before the PR merges; none shipped in a release. 1) REPLICAOF leaked the previous replica task (pre-existing, dominant signal). `REPLICAOF host port` spawned a fresh run_replica_task without stopping the old one, and `REPLICAOF NO ONE` only flipped the role: the old task kept streaming AND applying. Each NO-ONE → re-attach cycle stacked one more live applier — replica INCR counters ran ~25-35% ABOVE the master (reproduced at shards=1 and shards=4). Fix: process-global REPLICA_TASK_EPOCH ticket. StartReplication and PromoteToMaster bump the generation; a superseded task exits at the reconnect-loop top, before snapshot load, and before applying any parsed chunk — it can never mutate the keyspace again. 2) Snapshot-vs-live exactly-once now rests on an offset cut, not on FIFO placement. Two review rounds found opposite failure modes for placement schemes on the PSYNC connection's own shard: - queued snapshot leg (drain-time capture): a local write between push and drain was in the body AND live-sent behind the registration → double-apply (reproduced, +35%); - inline capture + queued registration: a same-cycle SPSC execute was neither in the body (applied after capture) nor live-sent (execute_batch direct-send runs before other_messages processes the registration) — with its bytes in the backlog and the offset advanced: silent loss + permanent replica ACK lag. Fix: every fan-out entry records cut = shard offset at body capture; every live record carries its per-shard end_offset; delivery requires end_offset > cut. Registration placement no longer matters, so ALL shards — including the PSYNC connection's own — use the same PrepareReplicaSync arm (the special-cased inline self-leg is gone). The cut/end_offset axis is the PER-SHARD counter, never the master offset (seed_master_offset diverges the two after AOF recovery). 3) Same-key wire ordering. SPSC-dispatched writes sent to replicas directly from the execute arm while local handler writes deferred through the self queue — a later-offset write could reach the wire before an earlier-offset same-key write, replaying out of the master's serialization order (analysis finding; not reproduced in ~10 black-box attempts). ALL live sends now flow through the self-queue ReplicaLiveFanout arm: per-shard wire order == FIFO order == offset order by construction. Tests (red/green: 1 and 2 reproduced red before their fixes): - tests/replication_multishard.rs +3: attach_under_write_no_double_apply (4-shard, 5x detach/re-attach under 4-writer pipelined INCR load, exact per-counter parity), singleshard_master_attach_under_write_control (same at shards=1 — the discriminating control that proved the task leak pre-existing), same_key_write_order_parity (12 conns APPEND-race 32 shared keys through both write paths; replica must byte-equal master). - Full regression: multishard 9/9, streaming 7/7, hardening 5/5, graph 5/5, aof_multidb_kill9 4/4, lib 4115 (monoio) + 3316 (tokio), clippy -D warnings both matrices, fmt — macOS and Linux VM. Mechanical: ShardMessage::RegisterReplica boxed (RegisterReplicaPayload; the extra offset fields pushed it past the 64-byte cap), ReplicaFanout tuple → struct with cut, increment_shard_offset returns the per-shard post-advance offset. Test-harness hardening surfaced by the Linux VM sweep (task #18 class): - replication_hardening now honors MOON_BIN (hardcoded ./target/release/moon exec'd the wrong-platform binary on the shared macOS/Linux checkout — all 5 tests failed to connect on the VM); - aof_multidb_kill9 wait_ready treats a connection RESET during moon's bootstrap→per-shard SO_REUSEPORT listener handover as "not ready yet" instead of panicking (3/4 VM failures, reproduced with main's binary too — environment-timing flake, not a code regression). Refs: task #20, task #36, PR #283 author: Tin Dang <tindang.ht97@gmail.com> * fix(replication): bounded PSYNC prepare wait + unregister on transfer failure (review) CodeRabbit round on PR #283: - PrepareReplicaSync reply collection is now bounded (30s timeout per leg): a wedged shard can no longer park the PSYNC task — and the fan-out registrations it holds — forever. On expiry the sync aborts with explicit unregister everywhere; the replica reconnects and retries. - Socket-write failures during the +FULLRESYNC/RDB transfer also unregister on every shard instead of leaving the entries to the passive next-write Disconnected prune. - docs/guides/clustering.md quotes the full tokio PSYNC error text. - CHANGELOG documents the 16K pre-RDB live-buffer limitation (overflow during a very large snapshot under sustained writes KICKS the replica loudly into a retry — never silent divergence). Verified: multishard 9/9, clippy -D warnings, fmt. Refs: task #20, PR #283 author: Tin Dang <tindang.ht97@gmail.com> --------- 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
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 actions/checkout from 4 to 6.
Release notes
Sourced from actions/checkout's releases.
... (truncated)
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
de0fac2Fix tag handling: preserve annotations and explicit fetch-tags (#2356)064fe7fAdd orchestration_id to git user-agent when ACTIONS_ORCHESTRATION_ID is set (...8e8c483Clarify v6 README (#2328)033fa0dAdd worktree support for persist-credentials includeIf (#2327)c2d88d3Update all references from v5 and v4 to v6 (#2314)1af3b93update readme/changelog for v6 (#2311)71cf226v6-beta (#2298)069c695Persist creds to a separate file (#2286)ff7abcdUpdate README to include Node.js 24 support details and requirements (#2248)08c6903Prepare v5.0.0 release (#2238)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)