Differing connection behaviour depending on whether connection is established at startup.

[amandam11]

I have a featurehub-javascript-node-sdk client.

If on startup it is unable to reach FeatureHub then the readiness fails, but there is never any re-attempt to get the connection back up. So even if FeatureHub comes back up, then it will not attempt to re-establish connection. So, for example there is no more logs once the initial readiness fails:

FeatureHub/Error:  Connection failed and repository not in ready state indicating persistent failure Event { type: 'error', message: 'getaddrinfo EAI_AGAIN featurehub' }
<then I see messages from our readiness listener saying its failed - and then nothing further, even after the FeatureHub server is restarted>

However, if on startup then the first attempt to connect to FeatureHub succeeds, if the FeatureHub server is later unavailable, then if I enable trace I can see that it reports the failure of the connection. But it then retries to get the connection, such that when FeatureHub is comes back up that it then manages to re-establish the connection. Whilst it has no connection to FeatureHub it uses the last value it got for the features.
For example, trace from connection going down, and then it retrying and then eventually reconnecting:

FeatureHub/Trace:  received bye { status: 'closed' }
FeatureHub/Trace:  refreshing connection in case of staleness Event { type: 'error', message: undefined }
FeatureHub/Trace:  refreshing connection in case of staleness Event {
  type: 'error',
  message: 'connect ECONNREFUSED 172.23.0.6:8085'
}
FeatureHub/Trace:  refreshing connection in case of staleness Event { type: 'error', message: 'getaddrinfo EAI_AGAIN featurehub' }
FeatureHub/Trace:  refreshing connection in case of staleness Event { type: 'error', message: 'getaddrinfo EAI_AGAIN featurehub' }
FeatureHub/Trace:  received ack { status: 'discover' }
FeatureHub/Trace:  received features [

Is this difference in behaviour intentional (as there hasn't been a chance to cache feature values)? Or is there benefit in the behaviour on startup being similar, i.e .that it goes into a retry and gets the connection as soon as it is able to.

[rvowles]

Hi Amanda!

Yes, this behaviour is intentional, as it's expected that the application would put the readiness into the health check url along with any other connections it might need to be considered ready to start. At start it needs to know the API exists/is valid at least once.