Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Feature: parallelize provider initialization at startup

Open
  • Is something wrong?
#636 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@mikemikimike is already working on this.

Since Aug 30, 2026.

Assessment

This issue has not been assessed yet.

Description

enhancement

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.

Dominant language
Go
Stars
1.2k
Forks
111
Avg merge
14h 43m
Merged PRs (30d)
142

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ENTERPILOT/GoModel

All issues in ENTERPILOT/GoModel

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.