xai-org/x-algorithm · error · ValueError

{namespace} is already exist in ShardingContext {self.name},

Error message

{namespace} is already exist in ShardingContext {self.name},{self.sharding_rules}

What it means

ShardingContext.register_sharding_rule keys rules by namespace string and refuses to register the same namespace twice. Registering a duplicate namespace raises this ValueError, which surfaces when make_sharding_context_from_config builds the context from your sharding config.

Source

Thrown at phoenix/xrex/models/sharding_context.py:63

            f"{name or 'unnamed'}={size}" for name, size in zip(self.names, self.shape)
        )
        return f"NamedShape({shape_str})"


class ShardingContext:
    def __init__(
        self,
        name: str,
        mesh: jax.sharding.Mesh,
        sharding_rules: dict[str, ShardingRule] | None = None,
    ):
        self.name = name
        self.mesh = mesh
        self.sharding_rules = {} if sharding_rules is None else sharding_rules

    def register_sharding_rule(self, namespace: str) -> Callable[[ShardingRule], None]:
        if namespace in self.sharding_rules:
            raise ValueError(
                f"{namespace} is already exist in ShardingContext {self.name},{self.sharding_rules}"
            )

        def _register_sharding_rule(rule: ShardingRule) -> "ShardingContext":
            self.sharding_rules[namespace] = rule

        return _register_sharding_rule

    def logical_axis_to_physical(
        self, logical_axis_name: str, namespace: str = "default", fallback_default: bool = True
    ):
        try:
            sharding_rule = self.sharding_rules.get(namespace)
            assert sharding_rule is not None, f"Unknown sharding namespace: {namespace}"
            physical_axes = sharding_rule(logical_axis_name)
        except Exception as e:
            if fallback_default:
                rank_logger.debug(f"Falling back to default namespace from {namespace}.")

View on GitHub (pinned to 24c60942c5)

Solutions

1. Inspect the merged config and remove the duplicate namespace entry before passing it to make_sharding_context_from_config
2. If overriding is intended, ensure the merge replaces rather than concatenates namespace keys
3. Use a distinct namespace name for genuinely different rules

Example fix

# before
sharding:
  attention: {in_dim: ["data"]}
# ...later merge adds another 'attention' block
# after
sharding:
  attention: {in_dim: ["data"], proj: ["model"]}  # single merged block per namespace

namespaces = [k for k in cfg['sharding']]
assert len(namespaces) == len(set(namespaces)), 'duplicate namespace in sharding config'

try:
    ctx = make_sharding_context_from_config(cfg)
except ValueError as e:
    if 'is already exist in ShardingContext' in str(e):
        raise ConfigError(f'duplicate namespace: {e}') from e
    raise

When it happens

Trigger: A sharding config dict (or merged configs) that contains the same namespace key twice, e.g. {'mlp': ..., 'mlp': ...} after YAML merging, or two config files both defining rules for 'attention'.

Common situations: YAML anchors/merge keys (<<: *base) duplicating a namespace; inheriting a base config and re-declaring a section instead of overriding it.

Related errors

• Unknown named dimension: {named_dim} for namespace: {namespa
• async_emb axis {axis!r} is not a mesh axis of {mesh}
• async_emb requires token shards to vary across the communica
• async_emb requires exactly one token shard per communicator
• async_emb tokens_per_batch={tokens_per_batch} does not shard

AI-assisted analysis of xai-org/x-algorithm@24c60942c5 (2026-08-28). Data as JSON: /api/errors/da2586d318e7ca4e. Report an issue: GitHub.