[BUG] Docker Connection Race Condition with Socket Proxy

[ElioDiNino]

Describe the Bug

See wollomatic/socket-proxy#83 and henrygd/beszel#1754 for the full context and how I fixed this for Beszel, but the TLDR is:

I use https://github.com/wollomatic/socket-proxy in a mode where the socket proxy reads Docker labels to assign socket permissions. Since Tinyauth boots up extremely quickly, the socket proxy occasionally blocks the version check request with a 403 before receiving the Docker labels and correctly updating permissions for future requests. While optimizations were made on the socket proxy side that reduced these occurrences, they are still happening with Tinyauth at times.

I am requesting that the following function (Docker initialization) add a single retry after a few seconds to get rid of this issue:

tinyauth/internal/service/docker_service.go

Lines 33 to 60 in 80bc871

	func NewDockerService(i DockerServiceInput) (*DockerService, error) {
	client, err := client.NewClientWithOpts(client.FromEnv)
	if err != nil {
	return nil, err
	}
	client.NegotiateAPIVersion(i.Ctx)
	_, err = client.Ping(i.Ctx)
	if err != nil {
	i.Log.App.Debug().Err(err).Msg("Docker not connected")
	return nil, nil
	}
	service := &DockerService{
	log: i.Log,
	client: client,
	context: i.Ctx,
	}
	service.isConnected = true
	service.log.App.Debug().Msg("Docker connected successfully")
	i.Ding.Go(service.watchAndClose, ding.RingMajor)
	return service, nil
	}

How to Reproduce

1. Deploy https://github.com/wollomatic/socket-proxy in the label-based mode (my setup).
2. Start Tinyauth (my setup) and see that sometimes the initial Docker connection is blocked so all Tinyauth label-based configurations don't work. I find this most commonly happens when the underlying OS is restarted.

Expected Behavior

Tinyauth retries the initial Docker connection after a few seconds of delay.

Additional Context

No response

Logs

No response

Operating System

Linux

Browser

N/A

Tinyauth Version

All versions

Docker Version (if applicable)

No response

Human Written Confirmation

• I confirm this issue was written by me and not generated by an LLM or AI assistant.

[steveiliop56]

Isn't that something a healthcheck would solve? See https://github.com/wollomatic/socket-proxy#container-health-check, you should be able to make Tinyauth depend on the proxy being healthy before starting.

[ElioDiNino]

Isn't that something a healthcheck would solve? See https://github.com/wollomatic/socket-proxy#container-health-check, you should be able to make Tinyauth depend on the proxy being healthy before starting.

No because it's not a race condition between the socket proxy and Tinyauth starting. The socket proxy is already running stably prior to Tinyauth. The race condition is that Tinyauth sometimes sends it's Docker setup request (right after bootup) before the Docker socket/daemon reports to the socket proxy Tinyauth's existence and labels, which configure it's allowed socket endpoints.

Let me know if that makes sense.

[steveiliop56]

Ahh so it's the socket-proxy being slow haha. Yeah I guess we can do a retry with exponential backoff like we do in LDAP.

[ElioDiNino]

Ahh so it's the socket-proxy being slow haha. Yeah I guess we can do a retry with exponential backoff like we do in LDAP.

I guess it's partly the socket proxy being slow to process, but also just Docker itself being slow broadcasting that information to the proxy. The backoff would be great, it only needs to happen for the setup function, since outside of that things run stably.

[steveiliop56]

@ElioDiNino can you please test with v5.2.0-beta.2.