Closing service does not reflect in seneca.find() or seneca.list({})

[Pulankit-so]

• [ ] After closing a service registered with mesh the methods find and list still returns the old list i.e even the closed pins are present, hence one cannot know the status of the target pattern. One alternative is to use {role: mesh,get:members} .

• [ ] But role:mesh,get:members only provides the pins registered with some other seneca instance and not the pins registered with itself i.e Seneca instance on which role:mesh,get:members is called.

[rjrodger]

This is due to https://github.com/senecajs/seneca-balance-client retaining an entry for those patterns. This is probably what you want as the service is only down for a minute?

Do you have a use-case for complete removal?

[Pulankit-so]

@rjrodger Basically my use-case is that, I want to obtain the health status of the target service i.e suppose we have two services running on mesh service A and service B such that, service A internally communicates with service B then if service B is down, Seneca gives a timeout error. so I wanted to put a health check before every request so that only those requests are allowed to pass for which target is running. Do suggest if there is a better way of doing this. Also, if any of the existing services is closed, role:mesh,get:members seems to be updated after a delay of one second . which again creates a problem for me as if any request comes in that one second it would lead to timeout.

[Pulankit-so]

if the service is down, how do I check it is down? , that is the main requirement .

[rjrodger]

Hi @Pulankit-so - OK. I still need some clarification. Why do you want to do this test yourself? The purpose of seneca-mesh is to handle this for you, so if a service dies, then it is removed. This takes about 1 second, as the network has to update. NOTE: this is much better than the 30 second time out for normal web services! :)

You should aim to run multiple instances of service B, with automated restarts, that way you can tolerate some failures.

Doing a health check before each call is not a good idea - what happens if the service goes down just after the check? What happens if the network is slow? What happens if service B is overloaded and just slow?

Could you describe your configuration for me? I'm very happy to help solve this problem for you, but I need to understand what you are trying to do.

Could you also describe the business use case? What is the feature you are trying to implement?

[Pulankit-so]

Hi @rjrodger thanks for the guide. Yeah agree with you, I should instead handle the error returned by Seneca for the purpose of returning custom errors.The errors code were not straight forward to understand and also I didn't find any documentation with error codes hence I wanted to do this on my end. Now I am handling no-current-target for detecting closure of the service. Although I do agree that in production this case will not arise as there will be multiple instances running. But still, i do feel Seneca should give a health status functionality as it might help in monitoring although the monitor is there, but it does not give much power to code & automate things.

[rjrodger]

@Pulankit-so you are right - this needs more documentation, and better handling of the error case. Thank you!