Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Feature: parallelize provider initialization at startup

Aperta
  • Qualcosa non va?
#636 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mikemikimike ci sta già lavorando.

Dal 30/8/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
Go
Stelle
1.2k
Fork
111
Merge medio
14h 43m
PR unite (30g)
142

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ENTERPILOT/GoModel

Tutte le issue di ENTERPILOT/GoModel

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.