Generated by the sls-pin-bump skill, operated by @awang01810.

The SLS pin bump in SERVER-132939 (PR #60406, pin 9ca39015 -> 665e99c1, 466 SLS commits) turns every disagg jstest suite red at fixture setup. Three independent config-drift breaks are involved. The gate only ever surfaced the first, because fixture setup dies there and never reaches the rest.

1. objectindexd and objectreadproxyd require a new flag_config section

ObjectIndexServerConfig and ObjectReadProxyServerConfig both gained a required top-level flag_config field, sibling to server_config and service_config. Both structs are #[serde(deny_unknown_fields)].

The reason these two daemons broke and logd / paged / pagematd / cms did not is the load path. config::load_config_with_optional_defaults(default, files) merges YAML over figment Serialized::defaults. Daemons that pass Some(default) absorb newly-added fields silently. objectindexd and objectreadproxyd pass None, so every field lacking #[serde(default)] must be present in the YAML.

Observed failure:

objectindexd-1 | Error: Error { kind: MissingField("flag_config"), ... }
objectindexd-1 exited with code 1
testdriver-1   | WARN TCP client connection failed reason=dns_nxdomain
                 remote_addr="http://objectindexd:30003/"
RuntimeError: Timed out after 300s waiting for SLS to be ready

The DNS error is downstream of the container exiting on config parse, not a separate problem.

objectreadproxyd depends_on: objectindexd, so it would have failed on the next gate run after fixing objectindexd alone.

Neither service mounted the flags-state file, so both the config block and the mount are needed. TargetingContext carries #[validate(length(min = 1))] on cell, environment and pod, so the values must be non-empty. Neither daemon is cell-scoped; SLS's own deployment configs target them at cell global.

2. CMS log ID 9999 is no longer recognized as a CMS log

SLS-9687 deleted CellMetadataLogConfig::get_current_cell_log_id() and collapsed the page materializer's CMS-log detection from log_id == self.cms_log_id || log_id.is_cms() to a bare log_id.is_cms().

LogId::is_cms() is a bit test: partition value 0x6 in the 4-bit field at bits 48..51. 9999 >> 48 == 0, so it fails. The page materializer would treat the CMS log as an ordinary data log: PSE lookup for it, PHYLOG seal machinery on an oplog-only log, and no materialized-offset filtering.

SLS changed 9999 to LogId::WELL_KNOWN_CMS (1700000000000000) across its own compose environments in the same commit, using per-cell offsets for multi-cell setups.

Scope

Two mongo-maintained config sites, matching the shape SLS uses in its own multi-cell environments:

• buildscripts/modules/atlas/sls-multicell-docker-compose.yml - the multicell fixture. Adds flag_config and the flags_state mount for both services, moves the CMS log IDs in cms_config and crs_config, and drops the now-deprecated-and-ignored pagematd_config.cell_metadata block, which hardcoded the stale ID.
• src/mongo/db/modules/atlas/jstests/disagg_storage/libs/slstest.js - the single-cell SLSBackupRestoreTest harness, which has its own objectindex/objectreadproxy service configs and its own CMS log ID. This is why disagg_backup_restore_jscore_passthrough is among the failing suites.

Plus the four jstests that pass an explicit CMS logId to startCMS and so override the default: mongod_waits_for_cms.js, mongod_reconnects_to_new_cms_for_pse_info.js, libs/sls_minimal_three_cell_test.js and log_segment_missing.js.

Landing

The old pin requires the old config shape, so this change cannot land separately from the pin bump. It goes into the same squash as SERVER-132939, the same way SERVER-131421 landed with SERVER-131334's bump.

Note that buildscripts/modules/atlas/sls-docker-compose.yml also carries stale CMS log IDs but is referenced by nothing in the repo - the fixture defaults to the multicell file and no suite overrides it. Left alone here; worth a separate cleanup.