Builder shouldn't quit on connection loss

[Fuuzetsu]

Currently builder terminates if it loses connection which means that we have to check every now and again and manually restart it. It'd be nice if it just waited for a connection to come back and resume its regular duties.

[cartazio]

what retry logic should it have?

[pgj]

I think the client already implements exponential backoff when it cannot connect to the server. Perhaps the same could also work here too.

[Fuuzetsu]

Just waiting until it can connect again and behaving as if it was started fresh (so send any lagging data or whatever) should be enough.

[AlainODea]

@Fuuzetsu are you still experiencing this? If not I can close this issue.

If so, how does this appear in logs when it disconnects? My builders generally survive network outages. I'm running them on a repurposed PC on a home network so there's nothing special shielding them from issues. It's possible that SMF (service management framework) is restarting the service..

This code in client.hs already does indefinate connection retries with 5 second sleeps between attempts:

`onConnectionDropped`
  do verbose' v user ("Connection dropped...sleeping for 5 seconds...")
    threadDelay (5 * 1000000)
    connLoop curDir baseDir user host

SOURCE:

ghc-builder/client/client.hs

Lines 86 to 89 in 1f47fcf

	`onConnectionDropped`
	do verbose' v user ("Connection dropped...sleeping for 5 seconds...")
	threadDelay (5 * 1000000)
	connLoop curDir baseDir user host

c host `onConnectionFailed`
  do verbose' v user ("Failed...sleeping for " ++ show secs ++ " seconds...")
    threadDelay (secs * 1000000)
    conn user host ((secs * 2) `min` 600)

SOURCE:

ghc-builder/client/client.hs

Lines 93 to 96 in 1f47fcf

	c host `onConnectionFailed`
	do verbose' v user ("Failed...sleeping for " ++ show secs ++ " seconds...")
	threadDelay (secs * 1000000)
	conn user host ((secs * 2) `min` 600)

[Fuuzetsu]

@AlainODea I haven't used this in years so I don't know, sorry.

[AlainODea]

@Fuuzetsu no worries at all.