Question: Is the fix in #3644 effective in version 2025.1.0.0?

[qnnn]

Hi, I have a question about this fix: #3644

While checking the code in 2025.1.0.0, it seems the logic introduced by this fix may not be triggered. I'm not sure if I missed something.

Could you confirm whether this fix is included and expected to work in 2025.1.0.0?

Thanks!

Which Component
Nacos Config

[uuuyuqi]

I checked the 2025.1.0.0 code path again, and I think this concern is valid.

The fix from #3644 is included in 2025.1.0.0. NacosContextRefresher stores the pushed config into NacosSnapshotConfigManager, and NacosPropertySourceBuilder can consume that snapshot before falling back to configService.getConfig(...).

However, in the default ConfigData refresh path, the reload does not appear to go through NacosPropertySourceBuilder. The Nacos refresh event is converted to a Spring Cloud RefreshEvent, and Spring Cloud refreshes the environment through ConfigDataContextRefresher. That path reloads Nacos config via NacosConfigDataLoader.

The problem is that NacosConfigDataLoader#pullConfig(...) directly calls configService.getConfig(dataId, group, timeout). It does not read from NacosSnapshotConfigManager, and it does not go through NacosPropertySourceBuilder.

So although #3644 is merged, its snapshot protection can be bypassed in the default ConfigData refresh flow in 2025.1.0.0. This means the original stale-read problem in a Nacos cluster can still happen in that path.

This is separate from #4312, which fixes file extension preservation during refresh. It does not address whether the pushed config snapshot from #3644 is consumed by the ConfigData reload path. @daguimu

[DragonFSKY]

I’d like to contribute a fix for the ConfigData reload path discussed here.

My understanding is that NacosContextRefresher already stores the pushed config content in NacosSnapshotConfigManager, but the default ConfigData refresh flow reloads config through NacosConfigDataLoader, which currently falls back directly to ConfigService#getConfig(...).

My proposed approach is to let NacosConfigDataLoader first consume NacosSnapshotConfigManager, and only fall back to ConfigService#getConfig(...) when no valid snapshot is available. This keeps the existing fallback behavior while applying the snapshot protection to the ConfigData path as well.

I opened PR #4319 with this change. Please let me know if this direction looks reasonable or if there are any concerns.