[Aionw]

Description

Step 1 of #4557: an object's in-flight tasks now live on the object's own record instead of in per-tenant side maps.

An object's processing marker and its replication, offload and promotion tasks were kept in four per-tenant maps keyed by the object's key, apart from its metadata (processing_keys, replication_tasks, offloading_tasks, promotion_tasks). Every path that ended an object or a task had to look the key up in each map and keep them consistent by hand, and a marker could outlive its object: the expiry sweep carried a branch for a processing key whose object was gone, and the accessor's double-erase crash of 2026-08-03 came from erasing the processing marker twice.

• ObjectRecord. TenantState's object map now holds an ObjectRecord, the object's ObjectMetadata next to a route::ObjectState with the processing flag and the three tasks (HeapOptional, so an object with no task pays a pointer per kind). They live and die with the object under the same shard lock. EraseMetadata still gives back what they hold (source refcounts, pending quota, the promotion in-flight count) before the record goes.
• Accessors. MetadataAccessorRW drops its iterators into the processing set and the replication map and exposes GetState(). The helpers that need a task (CancelQueuedOffloadTask, CleanupStaleHandles, CancelPromotionTaskForRemovedReplicas, ErasePromotionTaskIfPresent) take the record or its state instead of a key.
• Expired-work sweep. DiscardExpiredProcessingReplicas walks a shard's objects once to collect those with work in flight, then runs its four passes over them in the same order, so a round costs N + 4I (main walks only its in-flight maps). It runs once per put_start_release_timeout_sec_ (10 minutes by default) or inside the eviction census, which already walks every object; a later step of [Track]: [Store] Land the tenant-first MasterService migration in staged PRs #4557 gives it an in-flight list so the walk drops to O(I).
• Not in this PR. Promotion candidates and the dynamic-replication pending records and cooldowns keep their maps: each has a periodic scan that would otherwise walk every object, and they move with PromotionCandidateTracker and DynamicReplicationController (steps 2 and 3 of [Track]: [Store] Land the tenant-first MasterService migration in staged PRs #4557).
• route::ObjectState is named after where it ends up: the striped object route keeps it in each key's slot (step 5 of [Track]: [Store] Land the tenant-first MasterService migration in staged PRs #4557). HeapOptional comes from the same series.

Behavior is unchanged: no RPC, snapshot or OpLog format changes.

Part of the code comes from #4370 by @CAICAIIs (the per-object state).

Module

• Mooncake Store (mooncake-store)

Type of Change

• Refactor

How Has This Been Tested?

Test commands:

cmake --build build -j16 -- -k
ctest -j12 -R 'master_service|promotion|offload|heap_optional|dynamic_replication|snapshot|master_scenario|tenant|evict|ssd'

Test results:

• Unit tests pass

• Integration tests pass (if applicable)

• Manual testing done (describe below)

• Build: the tree builds with GCC 16 (RelWithDebInfo, BUILD_UNIT_TESTS=ON). The only targets that fail, chaosctl (sleep not declared) and ordered_oplog_writer_test (libaio link), fail the same way on main.

• GCC 11.4 (Ubuntu 22.04, the CI floor): every changed translation unit passes -fsyntax-only, except file_storage.cpp, whose change is one comment line and which needs liburing headers the check container does not have.

• Tests: 58 of 58 pass, including master_service_test, master_service_test_for_snapshot, master_service_ha_test, promotion_on_hit_test, master_service_ssd_test, offload_on_evict_test, master_service_offload_scenario_test, master_service_processing_key_double_erase_test, dynamic_replication_test, master_service_tenant_quota_test, snapshot_child_process_test, the master_service_*_scenario_test suites and the new heap_optional_test.

• Formatting: ./scripts/code_format.sh --check --changed-lines --base origin/main is clean with clang-format 20.1.8.

Checklist

• I have performed a self-review of my own code
• I have formatted my code using ./scripts/code_format.sh
• I have run pre-commit on the files changed in this PR and all hooks pass
• I have updated the documentation (if applicable)
• I have added tests to prove my changes are effective (heap_optional_test; the existing suites cover the moved state)
• For changes >500 LOC: I have filed an RFC issue ([RFC]: Tenant-First Object-Level Metadata Locking #3670, tracked in [Track]: [Store] Land the tenant-first MasterService migration in staged PRs #4557)

AI Assistance Disclosure

• AI tools were used (specify below)

AI assistance was used for the refactor and to draft this description. The submitter has reviewed every changed line and can defend the change end to end.

[Icedcoco]

LGTM pending CI

[CAICAIIs]

Before this PR these four passes walked the in-flight sets, so a round cost O(in-flight). They now walk every object of the tenant (11163, 11263, 11388, 11406), and BatchEvict calls this per shard under the shard write lock, so a round is 4N whether or not anything is in flight.

Could we collect the objects with anything in flight in one pass and run the same four passes over that collection? A round would then be N + 4I, with the pass order unchanged.

[Aionw]

What you've said already covered in following PR. This PR is intentionally doing this way to keep change small and easy to review.

[Aionw]

Reconsidered: done in 899316c. One walk now collects the objects with work in flight, and the four passes run over that collection in the same order, so a round is N + 4I instead of 4N. Getting it down to O(I) like main needs an in-flight list on the record, which comes in a later step of #4557.

[CAICAIIs]

lgtm