pkg/services: add services.Config.NewServices/Internals helper #204
Conversation
jmank88
force-pushed
the
service-workers
branch
from
104050e
to
a48a03c
Compare
jmank88
force-pushed
the
service-workers
branch
from
a48a03c
to
47c53ca
Compare
jmank88
had a problem deploying
to
integration
GitHub Actions
Failure
jmank88
force-pushed
the
service-workers
branch
from
47c53ca
to
41aac5f
Compare
jmank88
had a problem deploying
to
integration
GitHub Actions
Failure
jmank88
force-pushed
the
service-workers
branch
from
41aac5f
to
055b33b
Compare
jmank88
had a problem deploying
to
integration
GitHub Actions
Failure
jmank88
force-pushed
the
service-workers
branch
from
055b33b
to
4eaf9fe
Compare
jmank88
had a problem deploying
to
integration
GitHub Actions
Failure
| return | ||
| } | ||
|
|
||
| // Output: |
There was a problem hiding this comment.
Is there a txtar like way to test against this output? That might be too brittle since the sub services are closed concurrently.
There was a problem hiding this comment.
Is there a txtar like way to test against this output?
It is already built-in. These execute like regular tests.
https://go.dev/blog/examples
That might be too brittle since the sub services are closed concurrently.
We can probably add a test-only hack to make the close deterministic 🤔
jmank88
force-pushed
the
service-workers
branch
from
4eaf9fe
to
1422cad
Compare
jmank88
force-pushed
the
service-workers
branch
from
1422cad
to
7bb4356
Compare
| return | ||
| } | ||
|
|
||
| func (s *service) HealthReport() map[string]error { |
There was a problem hiding this comment.
As a fail-safe, we could track when this is called, and if it is never called, or not called often enough, then we could periodically emit to logs instead 🤔
jmank88
force-pushed
the
service-workers
branch
from
7bb4356
to
6bb7b30
Compare
jmank88
force-pushed
the
service-workers
branch
from
6bb7b30
to
a5aae0e
Compare
| func (e *Engine) HealthEvent(err error) { e.healthEvent(err) } | ||
|
|
||
| // SetUnhealthy records a condition key and an error, which causes an unhealthy report, until SetHealthy(condition) is called. | ||
| func (e *Engine) SetUnhealthy(condition string, err error) { | ||
| e.condsMu.Lock() | ||
| defer e.condsMu.Unlock() | ||
| e.conds[condition] = fmt.Errorf("%s: %e", condition, err) | ||
| } | ||
|
|
||
| // SetHealthy removes a condition and error recorded by SetUnhealthy. | ||
| func (e *Engine) SetHealthy(condition string) { | ||
| e.condsMu.Lock() | ||
| defer e.condsMu.Unlock() | ||
| delete(e.conds, condition) | ||
| } | ||
|
|
||
| // Unhealthy causes an unhealthy report, until the returned func() is called. | ||
| // Use this for simple cases where the func() can be kept in scope, and prefer to defer it inline if possible: | ||
| // | ||
| // defer Unhealthy(fmt.Errorf("foo bar: %i", err))() | ||
| // | ||
| // See SetUnhealthy for an alternative API. | ||
| func (e *Engine) Unhealthy(err error) func() { |
There was a problem hiding this comment.
I am still not satisfied with these names. I think that these four different operations are fundamental, but I'm not sure what to call them that would be more intuitive than this... 🤔
| }) | ||
| } | ||
|
|
||
| func (s *service) Close() error { |
There was a problem hiding this comment.
@DeividasK We could prioritize Stop while adapting Close easily here without spamming it in every implementation.
| func (s *service) Close() error { | |
| func (s *service) Close() error { return s.Stop() } | |
| func (s *service) Stop() error { |
This PR introduces
services.Config.NewServiceswithservices.Internalsto help createservices.Services in a standard way that reduces boilerplate and the risk of mistakes that comes with re-implementing logger naming, health reporting, sub-service management, etc.Blocked by: