Logs S3 cold-storage retention is a no-op via the Workspace Retention UI on v0.126 (empty coldStorageVolume); #9371 fix incomplete

Bug description

On self-hosted SigNoz v0.126.0, setting Logs → Move to S3 under Settings → Workspace → Retention Controls returns 200 "custom retention TTL has been successfully set up" but is a complete no-op: the signoz_logs.logs_v2 table gets no TO VOLUME 's3', _retention_days_cold stays 0, and the delete-days change isn't applied either. Re-opening Settings shows the Move-to-S3 field empty.

The frontend POSTs an empty coldStorageVolume:

{ "type": "logs", "defaultTTLDays": 30, "coldStorageVolume": "", "coldStorageDurationDays": 0, "ttlConditions": [] }

This is the same bug as #9060 and #9190. PR #9371 (merged 2025-10-28) closed #9190 but did not fully fix it — a maintainer noted in that PR's review "once I go back to settings the move to s3 value is empty," and we reproduce it on v0.126 (after #9371). Likely related: our S3 disk reports type=ObjectStorage (not s3) in system.disks, which the FE cold-storage-disk detection appears to mishandle.

Expected behavior

Saving Logs Move-to-S3 should POST the selected disk + duration, e.g.:

{ "type": "logs", "defaultTTLDays": 90, "coldStorageVolume": "s3", "coldStorageDurationDays": 14, "ttlConditions": [] }

so the backend (SetTTLV2) issues ALTER TABLE signoz_logs.logs_v2 ... MODIFY TTL ... + toIntervalDay(<cold>) TO VOLUME 's3', and re-opening Settings shows the saved Move-to-S3 value.

How to reproduce

1. Go to Settings → Workspace → Retention Controls.
2. For Logs, the cold-storage field is a bare unit dropdown (Hours/Days) with no value input — you can't enter a Move-to-S3 duration. Set a delete period and Save (returns 200 success).
3. Inspect the table: SHOW CREATE TABLE signoz_logs.logs_v2 — there is no TO VOLUME 's3' and the TTL / _retention_days_cold is unchanged. Re-open Settings → the Move-to-S3 value is empty.
4. (DevTools → Network) the POST /api/v2/settings/ttl request payload shows coldStorageVolume: "", coldStorageDurationDays: 0. The GET /api/v2/settings/ttl response shows cold_storage_ttl_days: -1 (no cold storage).

Version information

• Signoz version: v0.126.0 (self-hosted, community chart)
• Browser version: Chrome 149.0.7827.201
• Your OS and version: macOS 15.7.7 (build 24G720)
• Your CPU Architecture(ARM/Intel): ARM (deployment runs on AWS Graviton/arm64; client is Apple Silicon)

Additional context

• Deployment: self-hosted SigNoz (community chart) on Kubernetes (EKS); 3-shard ClickHouse v25.5.6 (chi-signoz-clickhouse-cluster-{0,1,2}), Altinity ClickHouse operator; nodes are ARM/Graviton.
• Storage: policy tiered (hot JBOD disks disk0..disk12 -> s3 volume, move_factor 0.1). The S3 disk is configured <type>s3</type> but system.disks reports its type as ObjectStorage (not s3).
• Round-trip is broken both ways: GET /api/v2/settings/ttl returns cold_storage_ttl_days: -1 (no cold storage) and default_ttl_days: 30, even when a TO VOLUME 's3' move TTL is present on the table — so the cold-storage value can't be read back, not just written.
• Likely root cause: frontend/src/container/GeneralSettings/GeneralSettings.tsx passes coldStorageDuration: 0 for logs and an empty coldStorageVolume; the cold-storage-disk detection may not match a disk whose type is ObjectStorage. The Logs row renders a cold-storage unit dropdown with no value input.
• Impact / workaround: cold-move can't be set via the UI, so we apply the move-TTL via a direct ClickHouse ALTER (what SetTTLV2 runs internally); the UI then diverges from the table, and a future "Save" would silently overwrite it.
• Ask: complete the FE fix for an S3 disk reporting type=ObjectStorage — populate coldStorageVolume/coldStorageDurationDays and confirm the value round-trips on re-open (which #9371's review noted it did not). Which release will include it?