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

Activity

1. uuuyuqi

   added

   area/nacosspring cloud alibaba nacosspring cloud alibaba nacos

   kind/bugMark as bugMark as bug

   help wanted

   good first issue

   on Apr 24, 2026
2. uuuyuqi commented on Apr 24, 2026

   

   uuuyuqi

   on Apr 24, 2026

   Collaborator

   More actions

   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

   👀React with 👀1Reacted by qnnn
3. DragonFSKY commented on May 3, 2026

   

   DragonFSKY

   on May 3, 2026

   Contributor

   More actions

   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.
4. EvanYao826

   added 2 commits that reference this issue on May 21, 2026

   fix: use config snapshot in NacosConfigDataLoader to fix stale config…

   ...

   This issue will close once commit 868ea6a is merged into the '2025.1.x' branch.

   868ea6a

   fix: use config snapshot in NacosConfigDataLoader to fix stale config…

   ...

   This issue will close once commit 4522b14 is merged into the '2025.1.x' branch.

   4522b14
5. oss-sentinel-ai commented on Jul 21, 2026

   

   oss-sentinel-ai

   on Jul 21, 2026

   More actions

   Issue Evaluation

   Category: question | Status: Answered

   PR #3644 ("修复 Nacos 集群模式下获取到旧配置问题") was merged on 2024-03-08 (commit f2bb845). The changes introduced by that fix — specifically the ready guard (AtomicBoolean) and the NacosConfigRefreshEvent handling in NacosPropertySourceRefreshListener — are present in version 2025.1.0.0.

   However, the fix operates on the legacy refresh path where property sources are NacosPropertySource instances. If you are using spring.config.import=nacos:... (the ConfigData path introduced in newer versions), the property sources in Environment are OriginTrackedMapPropertySource — not NacosPropertySource. In that case, the instanceof NacosPropertySource check in the listener always fails, and the refresh logic is never reached.

   TL;DR: The fix from #3644 is included in 2025.1.0.0, but it may not be effective if you are using the spring.config.import configuration path. See #4337 and #4331 for details on the ConfigData-path issue.

   ---

   Automated evaluation by github-manager-bot