stacklok / toolhive / 24274112989

push

github

Fix stale config in registry routes and WorkloadService (#4751)

* Fix stale config in registry routes and WorkloadService

Two independent config snapshots caused inconsistency after enterprise
registry changes:

1. NewRegistryRoutes/NewRegistryRoutesForServe created separate
   config.Provider instances for configProvider and configService.
   This meant getRegistry responses mixed live metadata (from configService)
   with stale server lists (from the old independent provider). Fix: create
   a single provider p and pass it to both.

2. WorkloadService.appConfig was a one-time snapshot taken at construction.
   After an enterprise registry change, new workloads got stale registry
   URLs written into their persisted RunConfig. Fix: store config.Provider
   and call GetConfig() at the point of use in BuildFullRunConfig.

Add tests verifying:
- configService and getCurrentProvider share the same provider instance
  (listRegistries returns consistent type/source and server count)
- WorkloadService.configProvider is initialized at construction

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* Address bot review: fix factory bypass and TOCTOU in WorkloadService

- Replace config.NewDefaultProvider() with config.NewProvider() in
  NewWorkloadService so a registered ProviderFactory is respected,
  consistent with the analogous fix in NewRegistryRoutes
- Hoist cfg := s.configProvider.GetConfig() once at the top of the
  relevant block in BuildFullRunConfig so both uses (ResolveRegistrySourceURLs
  and DisableUsageMetrics) see the same config snapshot within a single call
- Add TestNewWorkloadService_RespectsRegisteredFactory to verify the
  factory-backed provider is actually used

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

11 of 11 new or added lines in 2 files covered. (100.0%)

56379 of 86074 relevant lines covered (65.5%)

61.67 hits per line