Is your feature request related to a problem? Please describe.
GoModel takes noticeably longer to start when many providers are configured, because provider initialization runs strictly sequentially. Each provider gets a synchronous availability probe with up to a 5 second timeout before moving to the next one, so N slow/unreachable providers can add up to N times the per-provider delay to startup, purely serialized.
Root cause: initializeProviders (internal/providers/init.go, around lines 238-283) loops over the sorted provider names with a plain for _, name := range names (line 247) and, for each one, creates the provider then runs its availability check synchronously with a per-provider 5 second timeout (lines 260-272) before moving to the next iteration.
Describe the solution you'd like
Run the per-provider create-and-probe work concurrently, bounded by a reasonable concurrency limit (for example a worker pool or a semaphore-limited goroutine fan-out), collecting results back into the registry once each provider's goroutine finishes. The deterministic sort of provider names (line 244) should stay for logging/registration order where it matters, but the actual create + probe work itself does not need to happen one at a time.
Care needed:
registry.RegisterProviderWithNameAndType, RecordAvailabilityCheck, and related registry calls need to be safe to call concurrently (or be serialized behind a mutex/channel if they are not already).- Error handling and logging per provider should stay attributable to that specific provider, same as today.
- The overall
count of successfully initialized providers still needs to be computed correctly under concurrency.
Describe alternatives you've considered
Leaving it sequential: works, but startup time scales linearly with the number of configured providers, which is a real, measurable delay for larger deployments (each unreachable/slow provider adds up to its full 5 second timeout to total startup time).
Additional context
This is a well contained, single-file change (internal/providers/init.go), but touches concurrency and shared registry state, so it needs care and test coverage (in particular: confirm registration order/logging stays sane, and that a mix of fast/slow/failing providers is all handled correctly) rather than being a trivial one-line fix.
Is your feature request related to a problem? Please describe.
GoModel takes noticeably longer to start when many providers are configured, because provider initialization runs strictly sequentially. Each provider gets a synchronous availability probe with up to a 5 second timeout before moving to the next one, so N slow/unreachable providers can add up to N times the per-provider delay to startup, purely serialized.
Root cause:
initializeProviders(internal/providers/init.go, around lines 238-283) loops over the sorted provider names with a plainfor _, name := range names(line 247) and, for each one, creates the provider then runs its availability check synchronously with a per-provider 5 second timeout (lines 260-272) before moving to the next iteration.Describe the solution you'd like
Run the per-provider create-and-probe work concurrently, bounded by a reasonable concurrency limit (for example a worker pool or a semaphore-limited goroutine fan-out), collecting results back into the registry once each provider's goroutine finishes. The deterministic sort of provider names (line 244) should stay for logging/registration order where it matters, but the actual create + probe work itself does not need to happen one at a time.
Care needed:
registry.RegisterProviderWithNameAndType,RecordAvailabilityCheck, and related registry calls need to be safe to call concurrently (or be serialized behind a mutex/channel if they are not already).countof successfully initialized providers still needs to be computed correctly under concurrency.Describe alternatives you've considered
Leaving it sequential: works, but startup time scales linearly with the number of configured providers, which is a real, measurable delay for larger deployments (each unreachable/slow provider adds up to its full 5 second timeout to total startup time).
Additional context
This is a well contained, single-file change (internal/providers/init.go), but touches concurrency and shared registry state, so it needs care and test coverage (in particular: confirm registration order/logging stays sane, and that a mix of fast/slow/failing providers is all handled correctly) rather than being a trivial one-line fix.