[GH-ISSUE #3028] [RFC]: Fixed-Lifecycle Soft Pin with Request-Level TTL and Deadline-Indexed Expiration #777

New issue

Closed

opened 2026-10-29 21:19:23 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented 2026-10-29 21:19:23 +00:00

Owner

Copy link

Originally created by @Lin-z-w on GitHub (Jul 21, 2026).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/3028

Changes proposed

Summary

This RFC proposes changing Mooncake Store soft pinning from an access-renewed lease into a fixed-lifecycle eviction-priority hint.

A soft pin starts when the first replica of a write becomes readable. Its deadline is fixed for that activation and is not extended by Get, Exist, group lease refresh, replica copy/move, or storage promotion. When the deadline is reached, the object becomes ordinary cache. A later write may explicitly enable soft pinning again.

The proposal also adds an optional request-level TTL, an explicit Preserve | Enable | Disable write action, and a deadline index so expiration cleanup processes only due objects instead of scanning all metadata.

Related work:

• Implementation prototype: https://github.com/kvcache-ai/Mooncake/pull/2909
• Group-retention consumer: https://github.com/kvcache-ai/Mooncake/pull/2835

Motivation

The current soft-pin representation retains a soft_pin_timeout after the deadline has passed. Read-lease refresh paths can subsequently move that timeout into the future, causing an expired soft pin to become active again simply because the object was accessed.

This behavior creates several problems:

• Soft pin duration is not fixed and can be extended indefinitely by reads.
• An object can regain soft-pin priority without an explicit write intent.
• Group reads can indirectly refresh every member's object-level soft pin.
• The soft-pin gauge can count expired metadata until another operation happens to normalize it.
• A periodic exact cleanup implemented as a full metadata scan costs O(total object count) even when few or no soft pins expire.
• The behavior is difficult to compose with group retention because object soft pin and group lifetime can accidentally refresh each other.

The desired behavior is a predictable priority lifetime suitable for both standalone objects and future group-retention policy.

Proposed semantics

1. A soft pin is committed when a write first changes the object from zero readable replicas to at least one readable replica.
2. Enable(ttl) sets a deadline relative to that completion time.
3. Reads grant only the ordinary read lease and never extend or reactivate the soft pin.
4. At now >= deadline, the object is treated as ordinary cache.
5. A later explicit Enable may start a new soft-pin lifetime.
6. Disable removes the committed soft pin when the write becomes readable.
7. Preserve retains an unexpired committed deadline across Upsert, but does not preserve an already expired deadline.
8. Enable with TTL = 0 is equivalent to committing ordinary cache.
9. Soft pin remains an eviction-priority hint. If allow_evict_soft_pinned_objects=true, an active soft-pinned object may still be selected by the existing second eviction pass.
10. Explicit removal APIs continue to remove soft-pinned objects.

Write API

Replace the ambiguous boolean write intent with an explicit action:

enum class SoftPinAction : uint8_t {
    PRESERVE = 0,
    ENABLE = 1,
    DISABLE = 2,
};

struct ReplicateConfig {
    // Existing fields omitted.
    SoftPinAction soft_pin_action{SoftPinAction::PRESERVE};
    std::optional<uint64_t> soft_pin_ttl_ms{};
};

Request rules:

• PRESERVE must not include soft_pin_ttl_ms.
• DISABLE must not include soft_pin_ttl_ms.
• ENABLE uses soft_pin_ttl_ms when present.
• ENABLE without an override uses the Master's default_kv_soft_pin_ttl.
• A request-level TTL above max_kv_soft_pin_ttl is rejected.
• Unknown action values are rejected.

PRESERVE is the default because a default Upsert should not silently remove an existing eviction-priority deadline. For a new Put, preserving an absent deadline simply creates ordinary cache unless the caller selects ENABLE.

The existing C ABI can retain its boolean field for the initial change and translate it as follows:

with_soft_pin=true  -> ENABLE with the Master default TTL
with_soft_pin=false -> PRESERVE

This keeps existing Go and Rust wrappers functional, although those wrappers will not expose explicit disable or request-level TTL until their APIs are extended.

Master configuration

Add:

max_kv_soft_pin_ttl = 24h by default

The Master validates that:

default_kv_soft_pin_ttl <= max_kv_soft_pin_ttl

Deadline arithmetic is checked when the soft pin is committed, not only at Master startup. If completion_now + ttl cannot be represented by system_clock::time_point, the deadline saturates at time_point::max() instead of overflowing.

Object state model

The object-level state is:

Disabled
Pending(action, ttl, eligible_replica_ids)
Active(deadline)

Pending is write intent and Active is committed eviction priority. Starting a write does not immediately apply the requested action because the object may never become readable.

The pending action is committed only when:

• the End operation completes a replica allocated or reused by the current write; and
• the object changes from zero completed replicas to at least one completed replica.

After commit, Pending is cleared. Later replica completions and duplicate End calls therefore do not refresh the deadline.

Replica IDs are used to associate Pending with the replicas of the current write. End currently carries no write-generation token, so it is not possible to distinguish every stale End from a newer same-client write. Adding a protocol-level operation token is outside this RFC.

Revoke, preemption, and processing cleanup

A partial Revoke must not unconditionally discard Pending.

Pending is retained while at least one eligible PROCESSING replica from the same write can still become the first readable replica. Pending is cleared when:

• the object is deleted;
• a newer Upsert preempts the write; or
• no eligible and valid PROCESSING replica remains.

Committed state is independent from Pending. An Upsert that has not yet become readable does not immediately consume or replace the previous committed deadline.

For size-changing Upsert, an unexpired committed deadline is carried into the replacement metadata. It remains subject to its original deadline while the new replicas are PROCESSING. An expired deadline is not carried into replacement metadata.

Deadline index

Add a private Master-level deadline index without changing MetadataShard:

min_heap<Entry(deadline, shard_index, tenant_scoped_key)>
latest_registration[tenant_scoped_key] = (deadline, shard_index)

The index has its own mutex and is ordered after metadata-shard locks in the lock hierarchy. Cleanup never holds the index mutex while acquiring a metadata-shard lock.

The index is updated when:

• an Enable action commits;
• an inherited active deadline is installed in replacement metadata;
• an active object is deleted;
• an operation explicitly disables or lazily expires the committed deadline; or
• restored metadata is successfully applied.

The index is derived runtime state and is not serialized in snapshots.

Expiration cleanup

The existing task-cleanup thread remains responsible for soft-pin expiration; this RFC does not add another thread.

Each cleanup cycle:

1. Pops heap entries with deadline <= now.
2. Discards entries that do not match the latest registration.
3. Groups remaining entries by metadata shard.
4. Acquires each affected shard's read lock once.
5. Looks up the object and clears the soft pin only if the metadata still has the same deadline.
6. Applies the aggregate gauge decrement after metadata updates.

The exact-deadline comparison prevents an old heap entry from clearing a soft pin that was subsequently re-enabled with a newer deadline.

Expiration therefore changes from:

O(total metadata objects) per cleanup cycle

to approximately:

O(number of due entries * log(heap size))

with metadata locks acquired only for shards containing due entries.

TTL updates and stale heap entries

Updating a deadline inserts a new heap entry and updates the latest-registration map. The old heap entry is lazily invalidated because std::priority_queue does not support efficient arbitrary deletion.

To prevent repeated TTL updates from growing the heap without bound, rebuild it from live registrations when:

heap_size > max(4096, live_registration_count * 2)

The factor of two limits stale entries to roughly the number of live registrations for large indexes and gives an amortized O(1) rebuild cost per update. The floor of 4096 avoids rebuilding a small heap after every few updates while still placing an absolute bound on stale entries for small live sets. These are internal constants rather than user-visible configuration.

Read and eviction paths

Get, Exist, and group lease refresh stop evaluating or mutating soft-pin state. They update only the ordinary read lease.

This removes an additional object-lock acquisition from read-heavy paths and ensures that reads cannot influence object soft-pin lifetime.

Eviction paths still evaluate now < deadline when deciding priority. Therefore an object receives no soft-pin protection after its deadline even if the periodic cleanup has not yet removed the stored deadline.

The soft-pin gauge converges within the existing cleanup interval rather than synchronously on every read. It represents normalized active metadata, not a clock-exact value at every instant between cleanup cycles.

Metrics

Metadata state transitions return a metric delta and an optional deadline-index mutation. The Master applies index and metric changes after releasing the object's spin lock.

The gauge changes once for each logical transition:

Disabled -> Active: +1
Active -> Disabled: -1
Active -> Active with a new deadline: 0

Object destruction remains responsible for decrementing an active committed soft pin. Index removal and metric ownership remain separate so stale heap entries cannot double-decrement the gauge.

Snapshot and HA semantics

Snapshots continue to serialize the committed soft-pin deadline already stored in object metadata. The heap and latest-registration map are not serialized.

During restore:

1. An expired soft deadline is normalized to Disabled.
2. The object then follows the existing lease-based restore survival rule.
3. If the ordinary read lease is still valid, the object is restored as ordinary cache.
4. If both the ordinary lease and soft deadline are expired, the existing restore cleanup may discard the object.
5. After successful metadata cleanup, the deadline index is rebuilt from surviving active deadlines.

If restoring one snapshot candidate fails and the Master falls back to another candidate, resetting metadata also clears the derived deadline index. This prevents registrations from a failed candidate from leaking into the next attempt.

This RFC does not change the snapshot wire format.

Separation from group retention

Object soft pin and group retention must remain separate priority sources:

object soft pin active
group retention active

Eviction policy may combine those sources, but group retention must not copy or refresh a group deadline into every member's committed object soft pin. This separation allows PR #2835 to use the fixed-lifecycle behavior without reintroducing per-member deadline refresh or state duplication.

Compatibility and rollout

This proposal assumes a coordinated stop-the-world upgrade of Master and C++/Python clients. Mixed old/new Master-client RPC compatibility is not a goal.

Compatibility implications:

• Replacing the C++/Python with_soft_pin field is a source-level breaking change.
• Default same-size Upsert changes from implicitly disabling soft pin to preserving an unexpired deadline.
• Size-changing Upsert becomes consistent with same-size Upsert under the explicit action model.
• The existing C ABI boolean remains available through translation to Enable or Preserve.
• Existing snapshots remain readable because the serialized object deadline representation is unchanged.

Alternatives considered

Continue lazy expiration on access

This avoids a background index but leaves metrics and metadata stale indefinitely for cold objects and ties cleanup behavior to read traffic.

Periodically scan all metadata

This is simple and exact at the sweep interval, but its cost scales with total object count rather than the number of active or expiring soft pins.

Put one heap in every metadata shard

This avoids a global index mutex but changes MetadataShard, duplicates heap management across 1024 shards, and requires every cleanup cycle to inspect many independent heaps. It is more invasive than needed for the initial implementation.

Use a timing wheel or indexed mutable heap

These structures can reduce stale entries or update cost, but introduce substantially more implementation and synchronization complexity. A min-heap plus latest-registration map is sufficient for the expected TTL granularity and update rate.

Non-goals

• Implementing group retention itself.
• Making soft pin an absolute no-eviction guarantee.
• Changing ordinary read-lease semantics.
• Changing Copy, Move, or promotion operations into soft-pin activation points.
• Adding a new background thread or per-shard deadline structures.
• Supporting rolling mixed-version Master-client RPC upgrades.
• Adding a write-generation token to PutEnd or UpsertEnd.

Feedback requested

The RFC especially requests feedback on:

• PRESERVE as the default write action;
• the source compatibility impact of replacing with_soft_pin in C++ and Python;
• bounded-delay gauge convergence versus read-path normalization;
• the global index and lazy-invalidation compaction policy; and
• keeping group retention as a separate eviction-priority source.

Before submitting a new issue...

• Make sure you already searched for relevant issues and read the documentation

Originally created by @Lin-z-w on GitHub (Jul 21, 2026). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/3028 ## Changes proposed ### Summary This RFC proposes changing Mooncake Store soft pinning from an access-renewed lease into a fixed-lifecycle eviction-priority hint. A soft pin starts when the first replica of a write becomes readable. Its deadline is fixed for that activation and is not extended by `Get`, `Exist`, group lease refresh, replica copy/move, or storage promotion. When the deadline is reached, the object becomes ordinary cache. A later write may explicitly enable soft pinning again. The proposal also adds an optional request-level TTL, an explicit `Preserve | Enable | Disable` write action, and a deadline index so expiration cleanup processes only due objects instead of scanning all metadata. Related work: - Implementation prototype: https://github.com/kvcache-ai/Mooncake/pull/2909 - Group-retention consumer: https://github.com/kvcache-ai/Mooncake/pull/2835 ### Motivation The current soft-pin representation retains a `soft_pin_timeout` after the deadline has passed. Read-lease refresh paths can subsequently move that timeout into the future, causing an expired soft pin to become active again simply because the object was accessed. This behavior creates several problems: - Soft pin duration is not fixed and can be extended indefinitely by reads. - An object can regain soft-pin priority without an explicit write intent. - Group reads can indirectly refresh every member's object-level soft pin. - The soft-pin gauge can count expired metadata until another operation happens to normalize it. - A periodic exact cleanup implemented as a full metadata scan costs `O(total object count)` even when few or no soft pins expire. - The behavior is difficult to compose with group retention because object soft pin and group lifetime can accidentally refresh each other. The desired behavior is a predictable priority lifetime suitable for both standalone objects and future group-retention policy. ### Proposed semantics 1. A soft pin is committed when a write first changes the object from zero readable replicas to at least one readable replica. 2. `Enable(ttl)` sets a deadline relative to that completion time. 3. Reads grant only the ordinary read lease and never extend or reactivate the soft pin. 4. At `now >= deadline`, the object is treated as ordinary cache. 5. A later explicit `Enable` may start a new soft-pin lifetime. 6. `Disable` removes the committed soft pin when the write becomes readable. 7. `Preserve` retains an unexpired committed deadline across Upsert, but does not preserve an already expired deadline. 8. `Enable` with `TTL = 0` is equivalent to committing ordinary cache. 9. Soft pin remains an eviction-priority hint. If `allow_evict_soft_pinned_objects=true`, an active soft-pinned object may still be selected by the existing second eviction pass. 10. Explicit removal APIs continue to remove soft-pinned objects. ### Write API Replace the ambiguous boolean write intent with an explicit action: ```cpp enum class SoftPinAction : uint8_t { PRESERVE = 0, ENABLE = 1, DISABLE = 2, }; struct ReplicateConfig { // Existing fields omitted. SoftPinAction soft_pin_action{SoftPinAction::PRESERVE}; std::optional<uint64_t> soft_pin_ttl_ms{}; }; ``` Request rules: - `PRESERVE` must not include `soft_pin_ttl_ms`. - `DISABLE` must not include `soft_pin_ttl_ms`. - `ENABLE` uses `soft_pin_ttl_ms` when present. - `ENABLE` without an override uses the Master's `default_kv_soft_pin_ttl`. - A request-level TTL above `max_kv_soft_pin_ttl` is rejected. - Unknown action values are rejected. `PRESERVE` is the default because a default Upsert should not silently remove an existing eviction-priority deadline. For a new Put, preserving an absent deadline simply creates ordinary cache unless the caller selects `ENABLE`. The existing C ABI can retain its boolean field for the initial change and translate it as follows: ```text with_soft_pin=true -> ENABLE with the Master default TTL with_soft_pin=false -> PRESERVE ``` This keeps existing Go and Rust wrappers functional, although those wrappers will not expose explicit disable or request-level TTL until their APIs are extended. ### Master configuration Add: ```text max_kv_soft_pin_ttl = 24h by default ``` The Master validates that: ```text default_kv_soft_pin_ttl <= max_kv_soft_pin_ttl ``` Deadline arithmetic is checked when the soft pin is committed, not only at Master startup. If `completion_now + ttl` cannot be represented by `system_clock::time_point`, the deadline saturates at `time_point::max()` instead of overflowing. ### Object state model The object-level state is: ```text Disabled Pending(action, ttl, eligible_replica_ids) Active(deadline) ``` `Pending` is write intent and `Active` is committed eviction priority. Starting a write does not immediately apply the requested action because the object may never become readable. The pending action is committed only when: - the End operation completes a replica allocated or reused by the current write; and - the object changes from zero completed replicas to at least one completed replica. After commit, Pending is cleared. Later replica completions and duplicate End calls therefore do not refresh the deadline. Replica IDs are used to associate Pending with the replicas of the current write. End currently carries no write-generation token, so it is not possible to distinguish every stale End from a newer same-client write. Adding a protocol-level operation token is outside this RFC. ### Revoke, preemption, and processing cleanup A partial Revoke must not unconditionally discard Pending. Pending is retained while at least one eligible PROCESSING replica from the same write can still become the first readable replica. Pending is cleared when: - the object is deleted; - a newer Upsert preempts the write; or - no eligible and valid PROCESSING replica remains. Committed state is independent from Pending. An Upsert that has not yet become readable does not immediately consume or replace the previous committed deadline. For size-changing Upsert, an unexpired committed deadline is carried into the replacement metadata. It remains subject to its original deadline while the new replicas are PROCESSING. An expired deadline is not carried into replacement metadata. ### Deadline index Add a private Master-level deadline index without changing `MetadataShard`: ```text min_heap<Entry(deadline, shard_index, tenant_scoped_key)> latest_registration[tenant_scoped_key] = (deadline, shard_index) ``` The index has its own mutex and is ordered after metadata-shard locks in the lock hierarchy. Cleanup never holds the index mutex while acquiring a metadata-shard lock. The index is updated when: - an `Enable` action commits; - an inherited active deadline is installed in replacement metadata; - an active object is deleted; - an operation explicitly disables or lazily expires the committed deadline; or - restored metadata is successfully applied. The index is derived runtime state and is not serialized in snapshots. ### Expiration cleanup The existing task-cleanup thread remains responsible for soft-pin expiration; this RFC does not add another thread. Each cleanup cycle: 1. Pops heap entries with `deadline <= now`. 2. Discards entries that do not match the latest registration. 3. Groups remaining entries by metadata shard. 4. Acquires each affected shard's read lock once. 5. Looks up the object and clears the soft pin only if the metadata still has the same deadline. 6. Applies the aggregate gauge decrement after metadata updates. The exact-deadline comparison prevents an old heap entry from clearing a soft pin that was subsequently re-enabled with a newer deadline. Expiration therefore changes from: ```text O(total metadata objects) per cleanup cycle ``` to approximately: ```text O(number of due entries * log(heap size)) ``` with metadata locks acquired only for shards containing due entries. ### TTL updates and stale heap entries Updating a deadline inserts a new heap entry and updates the latest-registration map. The old heap entry is lazily invalidated because `std::priority_queue` does not support efficient arbitrary deletion. To prevent repeated TTL updates from growing the heap without bound, rebuild it from live registrations when: ```text heap_size > max(4096, live_registration_count * 2) ``` The factor of two limits stale entries to roughly the number of live registrations for large indexes and gives an amortized `O(1)` rebuild cost per update. The floor of 4096 avoids rebuilding a small heap after every few updates while still placing an absolute bound on stale entries for small live sets. These are internal constants rather than user-visible configuration. ### Read and eviction paths `Get`, `Exist`, and group lease refresh stop evaluating or mutating soft-pin state. They update only the ordinary read lease. This removes an additional object-lock acquisition from read-heavy paths and ensures that reads cannot influence object soft-pin lifetime. Eviction paths still evaluate `now < deadline` when deciding priority. Therefore an object receives no soft-pin protection after its deadline even if the periodic cleanup has not yet removed the stored deadline. The soft-pin gauge converges within the existing cleanup interval rather than synchronously on every read. It represents normalized active metadata, not a clock-exact value at every instant between cleanup cycles. ### Metrics Metadata state transitions return a metric delta and an optional deadline-index mutation. The Master applies index and metric changes after releasing the object's spin lock. The gauge changes once for each logical transition: ```text Disabled -> Active: +1 Active -> Disabled: -1 Active -> Active with a new deadline: 0 ``` Object destruction remains responsible for decrementing an active committed soft pin. Index removal and metric ownership remain separate so stale heap entries cannot double-decrement the gauge. ### Snapshot and HA semantics Snapshots continue to serialize the committed soft-pin deadline already stored in object metadata. The heap and latest-registration map are not serialized. During restore: 1. An expired soft deadline is normalized to Disabled. 2. The object then follows the existing lease-based restore survival rule. 3. If the ordinary read lease is still valid, the object is restored as ordinary cache. 4. If both the ordinary lease and soft deadline are expired, the existing restore cleanup may discard the object. 5. After successful metadata cleanup, the deadline index is rebuilt from surviving active deadlines. If restoring one snapshot candidate fails and the Master falls back to another candidate, resetting metadata also clears the derived deadline index. This prevents registrations from a failed candidate from leaking into the next attempt. This RFC does not change the snapshot wire format. ### Separation from group retention Object soft pin and group retention must remain separate priority sources: ```text object soft pin active group retention active ``` Eviction policy may combine those sources, but group retention must not copy or refresh a group deadline into every member's committed object soft pin. This separation allows PR #2835 to use the fixed-lifecycle behavior without reintroducing per-member deadline refresh or state duplication. ### Compatibility and rollout This proposal assumes a coordinated stop-the-world upgrade of Master and C++/Python clients. Mixed old/new Master-client RPC compatibility is not a goal. Compatibility implications: - Replacing the C++/Python `with_soft_pin` field is a source-level breaking change. - Default same-size Upsert changes from implicitly disabling soft pin to preserving an unexpired deadline. - Size-changing Upsert becomes consistent with same-size Upsert under the explicit action model. - The existing C ABI boolean remains available through translation to `Enable` or `Preserve`. - Existing snapshots remain readable because the serialized object deadline representation is unchanged. ### Alternatives considered #### Continue lazy expiration on access This avoids a background index but leaves metrics and metadata stale indefinitely for cold objects and ties cleanup behavior to read traffic. #### Periodically scan all metadata This is simple and exact at the sweep interval, but its cost scales with total object count rather than the number of active or expiring soft pins. #### Put one heap in every metadata shard This avoids a global index mutex but changes `MetadataShard`, duplicates heap management across 1024 shards, and requires every cleanup cycle to inspect many independent heaps. It is more invasive than needed for the initial implementation. #### Use a timing wheel or indexed mutable heap These structures can reduce stale entries or update cost, but introduce substantially more implementation and synchronization complexity. A min-heap plus latest-registration map is sufficient for the expected TTL granularity and update rate. ### Non-goals - Implementing group retention itself. - Making soft pin an absolute no-eviction guarantee. - Changing ordinary read-lease semantics. - Changing Copy, Move, or promotion operations into soft-pin activation points. - Adding a new background thread or per-shard deadline structures. - Supporting rolling mixed-version Master-client RPC upgrades. - Adding a write-generation token to PutEnd or UpsertEnd. ### Feedback requested The RFC especially requests feedback on: - `PRESERVE` as the default write action; - the source compatibility impact of replacing `with_soft_pin` in C++ and Python; - bounded-delay gauge convergence versus read-path normalization; - the global index and lazy-invalidation compaction policy; and - keeping group retention as a separate eviction-priority source. ### Before submitting a new issue... - [x] Make sure you already searched for relevant issues and read the [documentation](https://kvcache-ai.github.io/Mooncake/)

bsakaguchi 2026-10-29 21:19:23 +00:00

• closed this issue
• added the
  RFC
  stale
  auto-closed
  labels

bsakaguchi commented 2026-10-29 21:19:24 +00:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Jul 21, 2026):

Thanks for opening this issue, @Lin-z-w!

Field	Value
Issue	#3028
GitHub user ID	99333079
Reporter	@Lin-z-w

A maintainer will triage this when possible. To help us respond faster, please include:

• Mooncake version or commit SHA
• Environment (OS, CUDA/driver, RDMA stack if relevant)
• Steps to reproduce and expected vs. actual behavior

Useful links: Documentation · Contributing guide

This message was posted automatically by the issue bot.

<!-- gh-comment-id:5034569741 --> @github-actions[bot] commented on GitHub (Jul 21, 2026): Thanks for opening this issue, @Lin-z-w! | Field | Value | |-------|-------| | **Issue** | #3028 | | **GitHub user ID** | `99333079` | | **Reporter** | @Lin-z-w | A maintainer will triage this when possible. To help us respond faster, please include: - Mooncake version or commit SHA - Environment (OS, CUDA/driver, RDMA stack if relevant) - Steps to reproduce and expected vs. actual behavior Useful links: [Documentation](https://kvcache-ai.github.io/Mooncake/) · [Contributing guide](https://github.com/kvcache-ai/Mooncake/blob/main/CONTRIBUTING.md) > This message was posted automatically by the issue bot.

bsakaguchi commented 2026-10-29 21:19:25 +00:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Oct 20, 2026):

This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

<!-- gh-comment-id:6282498660 --> @github-actions[bot] commented on GitHub (Oct 20, 2026): This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

bsakaguchi commented 2026-10-29 21:19:25 +00:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Oct 27, 2026):

Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

<!-- gh-comment-id:6433834359 --> @github-actions[bot] commented on GitHub (Oct 27, 2026): Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

te-coro

staryxchen-tent-capability-research

feature/musa-ep-jit

zxpdemonio/fix-tent-bootstrap-admission

add-store-rs-tone-tests

scatter-rdma-completion-pr2

P2P-Mooncake-Store

release/v0.3.14

feat/tent-rdma-adaptive-adapter

fix/ep-local-counter-gpu-scope

codex/kvcs-oplog-eviction

give-me-a-star

cruz/mooncake-kvcs-lowlevel-pr1-20261008

ylt-handshake-limits

ci/rocm-e2e-tent

sima/docs-pypi-downloads

fix-ci/hicache-mooncake-metadata-loopback

sima/cuda-driver-loading

sima/ci-performance-gate

fix/tent-rdma-unknown-topology-rail-pairing

ci/tent-e2e-dual-job

mc-patch-1

codex/p2p-merge-prerequisites

sima/store-hca-numa-placement

codex/p2p-merge-cli

codex/p2p-merge-ipv6

copilot/fix-ctests-job-failure

czh/pg-device-collectives-pr6

dependabot/cargo/mooncake-store-rs/pyo3-0.29.0

czh/pg-device-collectives-pr5

codex/segment-pool-master-cutover

sima/nightly-ci-recovery

ci/tent-params

stmatengss-patch-1

dependabot/cargo/mooncake-store-rs/rand-0.8.8

dependabot/cargo/mooncake-store-rs/opentelemetry_sdk-0.32.1

dependabot/cargo/mooncake-store-rs/xxhash-rust-0.8.16

codex/migrate-store-rest-service

fix/tone-wheel-arch-selection

czh/pg-device-collectives-pr4

czh/pg-device-collectives-pr3

ketong/fix_moe_tc

copilot/fix-test-wheel-ubuntu-job

fix/ci-wheel-torch-pg-pin

codex/migrate-structured-object-storage

codex/migrate-allocator-python

codex/migrate-vllm-python

codex/migrate-shared-segment

ci/fix_sgl_eval_install

codex/segment-pool-nof-placement-cleanup

feat/pip-native-release

copilot/bugfix-ha-standby-promotion

copilot/mooncake-store-transport-settings

copilot/fix-tensor-support-issues

copilot/optimize-rl-direction

copilot/mooncake-storeagentic-workflow

copilot/fix-client-reconnect-timeout

copilot/mooncake-error-debugging

copilot/mooncake-ipv6-support

feat/nccl-host-python-api

dependabot/go_modules/mooncake-p2p-store/src/p2pstore/google.golang.org/grpc-1.82.1

copilot/migrate-and-move-operations

copilot/migrate-and-move-operations-again

refactor/centralize-env-vars

idhanani/mooncake-retain-groups

copilot/codeownerreviewer

copilot/give-feedback-on-issue-2123

copilot/create-issue-rfc

copilot/break-cuda-monopoly-logic

copilot/compare-cudamemcpy-cu12-cu13

copilot/report-ci-error-issue

copilot/research-commit-history-analysis

copilot/explain-mooncake-store-service

copilot/analyze-project-functionality

copilot/sub-pr-1680

copilot/review-pr-1680

copilot/sub-pr-1597

copilot/fix-github-actions-job-failure

copilot/move-test-sglang-integration-job

v0.3.14

v0.3.14-pre-4

v0.3.14-pre-3

v0.3.14-pre-2

v0.3.14-pre

v0.3.14-rc1

v0.3.13.post1

v0.3.13-rc2

v0.3.13-rc1

v0.3.13

v0.3.12.post1

v0.3.12

v0.3.11-rc1

v0.3.11.post1

v0.3.11

v0.3.10.post2

v0.3.10.post1

v0.3.10

v0.3.9

v0.3.8.post1

v0.3.8

v0.3.7.post2

v0.3.7.post1

v0.3.7

v0.3.6.post1

v0.3.6

v0.3.5

v0.3.4.post2

v0.3.4.post1

v0.3.4

v0.3.3.post2

v0.3.3.post1

v0.3.3

v0.3.2.post1

v0.3.2

v0.3.1

v0.3.0

v0.3.0-beta

v0.3.0-alpha

v0.2.0

Labels

Clear labels   

ascend

  

auto-closed

  

bug

  

bug

  

CI/Build

  

Common

  

documentation

  

enhancement

  

feature request

  

good first issue

  

help wanted

  

high priority

  

MetaX

  

nightly-failure

  

pull-request

Mirrored from GitHub Pull Request

  

PyTorch Backend

  

question

  

RFC

  

Roadmap

  

stale

  

Store

  

Tests

  

Transfer Engine

No labels

ascend

auto-closed

bug

bug

CI/Build

Common

documentation

enhancement

feature request

good first issue

help wanted

high priority

MetaX

nightly-failure

pull-request

PyTorch Backend

question

RFC

Roadmap

stale

Store

Tests

Transfer Engine

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kvcache-ai/Mooncake#777

No description provided.