Although there is a compile time check on the type, it will always
succeed due to the Unimplemented embedding requirement.
As a result, this PR also changes Unimplemented calls to Unsafe calls,
which were added later "for those that prefer their code to break"; the
comments on these state:
// UnsafeXServiceServer may be embedded to opt out of forward compatibility for this service.
// Use of this interface is not recommended, as added methods to XServiceServer will
// result in compilation errors.
See https://github.com/grpc/grpc-go/issues/4500#issuecomment-852597871
for some more context.
I think we're fine with compilation errors though; we own both the
server and client side of things and generally are going to add new
methods only when we intend to also add them on the client side.
Notably, what the comment does not indicate is that it will break at
runtime; already it should return a suitable (404 or 405) error if the
client requests a method that does not exist.
This fixes occurences of a loop variable being captured in parallel
tests. With the previous code, only the last test case is actually
exercised. To work around this problem, we create a local copy of the
range variable before the parallel test, as suggested in the
documentation for the `testing` package:
https://pkg.go.dev/testing#hdr-Subtests_and_Sub_benchmarks
Issues were found automatically using the `loopvarcapture` linter.
* Move the server daemons into their own package
With this change the internal/server package now is dedicated to the server domain (workers and controllers) and not to the server daemons.
The hope is that this will make it easier to keep the daemons decoupled from the representation of the servers in the database.
Irena Rindos
Jeff Mitchell
Johan Brandhorst-Satzkorn
Renato Costa
Jim
Todd