Reviewing files that changed from the base of the PR and between fb9d36e and 30bb3b4.

• docs/redoc/master/openapi.json
• src/common/metrics.rs
• src/common/telemetry_ops/cluster_telemetry.rs
• src/common/telemetry_ops/conversions.rs

• GitHub Check: test-shard-snapshot-api-s3-minio
• GitHub Check: test-consistency
• GitHub Check: test-consensus-compose
• GitHub Check: Test Python bindings
• GitHub Check: integration-tests-consensus
• GitHub Check: rust-tests (windows-latest)
• GitHub Check: rust-tests (macos-latest)
• GitHub Check: integration-tests
• GitHub Check: rust-tests (ubuntu-latest)
• GitHub Check: e2e-tests
• GitHub Check: lint

src/common/telemetry_ops/cluster_telemetry.rs (2)

83-84: LGTM!

The new field follows the established pattern for optional fields in ClusterTelemetry. The Option<bool> type with skip_serializing_if annotation provides backward compatibility when the field is not available (e.g., during gRPC conversions).

---

139-139: LGTM!

The field is correctly populated from cluster settings, following the same pattern as the enabled field (Line 100). Both are configuration flags that are unconditionally available when telemetry is collected, which is appropriate for their use case.

src/common/metrics.rs (1)

512-520: LGTM!

The destructuring correctly acknowledges the new field using explicit field ignoring (: _), which aligns with the coding guidelines. This ensures that any future fields added to ClusterTelemetry will require explicit handling here.

As per coding guidelines, explicit field ignoring is preferred over the catch-all .. pattern.

docs/redoc/master/openapi.json (1)

13420-13428: Schema addition looks correct; consider whether nullable matches actual serialization (null vs omitted).

The JSON structure and optionality (not in required) look good. If the API omits resharding_enabled when unknown/unset (rather than returning null), consider dropping nullable: true (or ensure the server can actually emit null) to avoid a minor spec/behavior mismatch. Optionally add a short description to clarify semantics for clients.

Proposed doc-only tweak (description)

           "resharding_enabled": {
+            "description": "Whether resharding is enabled in the cluster configuration.",
             "type": "boolean",
             "nullable": true
           }

src/common/telemetry_ops/conversions.rs (2)

147-149: LGTM! Consistent field initialization pattern.

The new resharding_enabled field follows the established pattern for fields that exist in the internal representation but not in the gRPC schema. The initialization to None with an explanatory comment is consistent with peer_metadata and metadata.

---

163-163: LGTM! Correct adherence to coding guidelines.

The explicit field ignoring using resharding_enabled: _ correctly follows the coding guideline preference over using .. in struct destructuring. This is consistent with the pattern for other fields (enabled, config, peer_metadata, metadata) that are not included in the gRPC message schema.

As per coding guidelines, explicit field ignoring is preferred to ensure new fields are consciously handled.