Allow changing a namespace's archival URI (e.g. to move archival to a new bucket)

[michal-billtech]

Is your feature request related to a problem? Please describe.

Once a namespace's history/visibility archival URI is set, it can never be changed. Disabling archival first does not help: UpdateNamespace rejects any URI change with Cannot update existing archival URI (common/namespace/archival_config_state_machine.go, the stateURISet && eventURISet && s.URI != e.URI check, unchanged on main / v1.32.1).

That makes it impossible to move archival to another bucket on a live namespace. Real cases:

• renaming or replacing an S3-compatible bucket (we are renaming our object-storage buckets to a new naming scheme; the namespace has years of workflows and ~1000 schedules, so re-creating it under a new name is not an option);
• moving to another provider/region, or a bucket that becomes unavailable;
• the multi-region case described in Global domain archival URI is immutable across clusters, creating history-loss risk during multi-region failover cadence-workflow/cadence#8010 (same rule inherited from Cadence).

The only alternatives today are keeping the old bucket forever for archival, or deleting/re-creating the namespace (new namespace ID, all executions and schedules lost).

What we found while evaluating this (v1.29.1)

• The rule comes from Cadence (Enable archival config per domain cadence-workflow/cadence#1351, Dec 2018: "Once archival is enabled a bucket name is always set and can never be changed"). We could not find a stated rationale beyond that.

• The URI is not persisted per execution or per archival task. The archival queue task executor resolves it from the namespace entry at execution time (service/history/archival_queue_task_executor.go), and reads (getArchivedHistory, ListArchivedWorkflowExecutions) also use only the namespace's current URI (service/frontend/workflow_handler.go).

• So the guard seems to protect against one thing: after a change, data archived under the old URI is no longer reachable unless it is copied under the same keys to the new location.

• In a local test with Cassandra, editing config.history_archival_uri / visibility_archival_uri in the namespace's NamespaceDetail blob directly in persistence worked:

  • the registry picked it up within seconds;
  • new archives went to the new bucket;
  • after copying the old objects, both old and new archived executions were readable.

  It works, but it is unsupported and risky: a bad blob breaks namespace loading cluster-wide, and it races with concurrent UpdateNamespace calls.

Describe the solution you'd like

A supported way to change the archival URI, for example:

• allow changing the URI through UpdateNamespace / temporal operator namespace update behind an explicit opt-in (e.g. a --force-archival-uri-change flag, possibly only while archival is disabled), with the new URI validated like on registration, and documentation that existing archives must be copied to the new location to stay readable; or
• support a list of read URIs (current URI for writes, previous URIs for reads), so archived data stays reachable without copying.

For global namespaces, the same opt-in would need to replicate consistently.

Additional context

Server 1.29.1, s3store provider (S3-compatible, s3ForcePathStyle). Happy to provide more details from the test.