alibaba/nacos · error · NacosException

-400

-400

Error message

wrong group name prefix of instance service name! it should be: %s, Instance: %s

What it means

Thrown by NacosNamingService.checkAndStripGroupNamePrefix when an Instance's serviceName is in compatibility mode (contains a group prefix like 'GROUP_NAME@@serviceName') but the embedded group does not match the groupName argument passed to the register/batch API. The client enforces consistency: if you supply a serviceName with a legacy '@@' group prefix, that prefix must equal the groupName parameter. Code CLIENT_INVALID_PARAM (-400).

Source

Thrown at client/src/main/java/com/alibaba/nacos/client/naming/NacosNamingService.java:727

        clientProxy.shutdown();
        namingFuzzyWatchServiceListHolder.shutdown();
        NotifyCenter.deregisterSubscriber(changeNotifier);
    }
    
    private void batchCheckAndStripGroupNamePrefix(List<Instance> instances, String groupName)
        throws NacosException {
        for (Instance instance : instances) {
            checkAndStripGroupNamePrefix(instance, groupName);
        }
    }
    
    private void checkAndStripGroupNamePrefix(Instance instance, String groupName)
        throws NacosException {
        String serviceName = instance.getServiceName();
        if (NamingUtils.isServiceNameCompatibilityMode(serviceName)) {
            String groupNameOfInstance = NamingUtils.getGroupName(serviceName);
            if (!groupName.equals(groupNameOfInstance)) {
                throw new NacosException(NacosException.CLIENT_INVALID_PARAM, String.format(
                    "wrong group name prefix of instance service name! it should be: %s, Instance: %s",
                    groupName,
                    instance));
            }
            instance.setServiceName(NamingUtils.getServiceName(serviceName));
        }
    }
    
    private void notifyIfSubscribed(String serviceName, String groupName,
        NamingSelectorWrapper wrapper)
        throws NacosException {
        if (clientProxy.isSubscribed(serviceName, groupName, StringUtils.EMPTY)) {
            NAMING_LOGGER.warn(
                "Duplicate subscribe for groupName: {}, serviceName: {}; directly use current cached to notify.",
                groupName, serviceName);
            ServiceInfo serviceInfo = serviceInfoHolder.getServiceInfo(serviceName, groupName);
            InstancesChangeEvent event = transferToEvent(serviceInfo);
            wrapper.notifyListener(event);

View on GitHub (pinned to 9b989acdf1)

Solutions

  1. Make the serviceName's '@@' prefix match the groupName argument, OR omit the prefix from serviceName and pass the group only via the groupName parameter.
  2. Sanitize instance service names before registration to strip any '@@' prefix when using the explicit-group overloads.
  3. Adopt one convention project-wide: either always use 'GROUP@@name' or always use separate (group, name) parameters.

Example fix

// before
instance.setServiceName("DEFAULT_GROUP@@order-service");
naming.registerInstance("order-service", "PROD_GROUP", instance); // throws -400

// after — keep them consistent
instance.setServiceName("order-service"); // no prefix
naming.registerInstance("order-service", "PROD_GROUP", instance);
Defensive patterns

Strategy: validation

Validate before calling

// Strip any @@ group prefix before using the explicit-group overloads
String raw = instance.getServiceName();
if (raw != null && raw.contains("@@")) {
    String embeddedGroup = raw.substring(0, raw.indexOf("@@"));
    if (!embeddedGroup.equals(groupName)) {
        throw new IllegalArgumentException("Service name group prefix mismatch");
    }
    instance.setServiceName(raw.substring(raw.indexOf("@@") + 2));
}

Prevention

When it happens

Trigger: Calling registerInstance(serviceName='DEFAULT_GROUP@@foo', groupName='OTHER') where the prefix DEFAULT_GROUP differs from OTHER; batch registerInstance with instances whose embedded group prefixes disagree with the supplied group; mixing legacy '@@'-prefixed service names with the explicit groupName overload.

Common situations: Migrating from the legacy single-name API (which embeds group via '@@') to the explicit (groupName, serviceName) overloads; copy-pasting service names that include a group prefix while also passing a different group argument; inconsistent group conventions across services.

Related errors


AI-assisted analysis of alibaba/nacos@9b989acdf1 (2026-08-14). Data as JSON: /api/errors/2d5448ee6c90814e. Report an issue: GitHub.