fix(start): a project made only of provider services could not start

startService errored with 'no container to start' whenever the
project-wide container listing came back empty, before the per-service
filtering that lets provider services pass through. A project whose
services are all provider-backed legitimately reaches the start phase
with zero containers. The empty-list error is now softened for
provider services only — a relay container deployed for published
endpoints still goes through the regular start path.

Signed-off-by: Nicolas De Loof <[email protected]>
This commit is contained in:
Nicolas De Loof
2026-10-02 17:35:20 +02:00
committed by Guillaume Lours
parent cf300b6cd8
commit 690ca3ff5f
+7 -1
View File
@@ -591,7 +591,6 @@ func (s *composeService) startService(ctx context.Context,
if service.Deploy != nil && service.Deploy.Replicas != nil && *service.Deploy.Replicas == 0 {
return nil
}
err := s.waitDependencies(ctx, project, service.Name, service.DependsOn, containers, timeout)
if err != nil {
return err
@@ -601,6 +600,13 @@ func (s *composeService) startService(ctx context.Context,
if service.GetScale() == 0 {
return nil
}
if service.Provider != nil {
// a provider-backed service usually has no container of its own
// (it gets one — the relay — only when the provider published
// endpoints), so a project made only of provider services
// legitimately reaches the start phase with no container at all
return nil
}
return errNoContainerToStart(service.Name)
}