Nacos config refresh does not work with spring.config.import on 2025.0.x: PropertySource name mismatch and file extension lost in NacosPropertySourceRefreshListener

[TAlcantara]

Which Component

Nacos Config (spring-alibaba-nacos-config)

---

Describe the bug

When using spring-alibaba-nacos-config:2025.0.0.0 with Spring Boot 3.5.9 and spring.config.import=nacos:..., remote configuration can be loaded successfully at startup, but runtime refresh does not work correctly after the config is changed in Nacos.

After debugging the refresh flow, I found two related problems:

1. NacosPropertySourceRefreshListener cannot always locate the existing Nacos PropertySource in Environment, because the lookup key used in refresh does not match the actual property source name used by the ConfigData import path.
2. NacosPropertySourceRefreshListener rebuilds the property source with "properties" as the file extension, which is incorrect for configs imported as yml/yaml/json/xml.

As a result, the runtime Environment still exposes old values after a Nacos config change.

---

Simplest demo

I do not have a public demo repo at the moment, but the issue can be reproduced with a minimal Spring Boot application using:

• Spring Boot 3.5.9
• spring-alibaba-nacos-config:2025.0.0.0
• nacos-client:2.3.2
• spring.config.import=nacos:...yml?group=DEFAULT_GROUP&refreshEnabled=true

Minimal configuration:

spring:
  application:
    name: demo-app
  config:
    import:
      - "nacos:${spring.application.name}.yml?group=DEFAULT_GROUP&refreshEnabled=true"
  nacos:
    config:
      group: DEFAULT_GROUP
      refresh-enabled: true

[dongyikuan919]

我看了下这块代码，问题描述里的两个点应该是同一个刷新链路里的断点。

在 spring-alibaba-nacos-config 这条 ConfigData 路径里，NacosConfigDataLoader#doLoad 最后返回的是：

return new ConfigData(propertySources, getOptions(context, resource));

也就是实际进入 Environment 的是 pullConfig() 里 NacosDataParserHandler.parseNacosData(configName, config, suffix) 解析出来的 PropertySource，其中 configName = group + "@" + dataId。但 NacosPropertySourceRefreshListener 刷新时用的是：

String sourceName = String.join(NacosConfigProperties.COMMAS, event.dataId, event.group);
PropertySource<?> prevpropertySource = target.get(sourceName);

这个名字更像旧的 NacosPropertySource 包装对象名，和 ConfigData 实际放进 Environment 的 group@dataId 对不上，所以这里很容易直接拿不到 prevpropertySource，后续 replace 根本不会发生。

另外即使能拿到，当前重建也固定写死了：

nacosPropertySourceBuilder.build(dataId, group, "properties", ...)

这会让 spring.config.import=nacos:xxx.yml?... 这种场景刷新后按 properties 解析，yaml/json/xml 的配置都会丢格式语义。

我觉得修复方向可以考虑：

1. refresh listener 不再按 dataId,group 直接查 Environment，而是复用 ConfigData loader 里的命名规则，或者在加载阶段记录 dataId/group/suffix -> actual PropertySource name(s) 的映射；
2. NacosConfigRefreshEvent 或 repository 里需要保留 suffix/fileExtension，刷新时用原始 suffix 重建；
3. 回归测试建议覆盖 spring.config.import=nacos:demo.yml?group=DEFAULT_GROUP&refreshEnabled=true：启动后改 Nacos 配置，触发 refresh，断言 Environment 中的值更新，并且 yaml 嵌套 key 能正常解析。

如果方向认可，我可以继续试着补一个最小 PR，把 ConfigData 路径的 name/suffix 信息串起来。

[wushiyuanmaimob]

▎ I can reproduce this issue on the 2025.0.x branch. The root cause is confirmed as described:
▎
▎ Defect 1: PropertySource name mismatch
▎ - ConfigData path uses group@dataId as the property source name (NacosConfigDataLoader.java:146)
▎ - RefreshListener looks for dataId,group (NacosPropertySourceRefreshListener.java:103)
▎ - Result: target.get(sourceName) always returns null, so the refresh never happens
▎
▎ Defect 2: File extension hardcoded
▎ - RefreshListener hardcodes "properties" as the file extension (NacosPropertySourceRefreshListener.java:108)
▎ - The actual extension (yml/json/xml) is stored in NacosItemConfig.suffix but not propagated to the refresh flow
▎
▎ Proposed fix:
▎ 1. Add suffix field to NacosPropertySource so the refresh listener can retrieve the correct format
▎ 2. Update NacosPropertySourceRefreshListener to compute the correct source name for ConfigData path (handle both group@dataId and dataId,group formats)
▎
▎ Would a PR addressing these two defects be welcome? I can provide a fix with regression tests.

[dongyikuan919]

Thanks for confirming and breaking it down.

I think the proposed direction is reasonable. For the first PR, it may be better to keep the scope small and focus on the ConfigData refresh path only:

1. preserve the original suffix/file extension from NacosItemConfig through to the refresh flow;
2. resolve the actual PropertySource name consistently with the ConfigData loader, while keeping compatibility with the old dataId,group name if needed;
3. add regression coverage for spring.config.import=nacos:demo.yml?...&refreshEnabled=true, especially a nested YAML key, so the hardcoded properties regression is covered.

One detail worth checking before implementation: if one Nacos dataId is parsed into multiple PropertySources, the mapping should not assume a single source name too early. Otherwise the fix may work for the simple case but still miss composite/parsed sources.

A PR with these tests should make the behavior much easier for maintainers to review.