Two failures, neither in this code.
internal/test/my_service could not build: `undefined: MyServiceServer`. Its
.psrpc.go half is gitignored on purpose (internal/test/.gitignore carries
**/*.psrpc.go) — generated, not committed — so a fresh checkout has the
.pb.go and none of the service code that goes with it, and nothing in the
gate ever generated it. It does now, from the plugin in this repo. Only the
psrpc half: the .pb.go beside it IS committed, and regenerating that too
rewrites it against whatever protoc the runner carries.
From the package directory, as gen.go does. paths=source_relative places
output beside the .proto AS NAMED, so running it from the root writes
my_service.psrpc.go into the root and every build then reports `found
packages psrpc and my_service in <root>`.
internal/bus dialled 127.0.0.1 for containers it had just started:
bustest.go:51: dial tcp 127.0.0.1:32769: connect: connection refused
CI runs the job inside a container with the host's /var/run/docker.sock
bound in, so nats and redis come up as SIBLINGS — published on the HOST's
loopback, while the job's own 127.0.0.1 is a different interface with
nothing on it. dockertest reports the daemon's view; the port it chose is
right and the host is not, so hostPort keeps the port and answers the host:
the bridge gateway from inside a container, loopback outside one, and
DOCKER_TEST_HOST ahead of both.
Verified against a real daemon: internal/bus goes from refused to ok in 18s,
and the gate's own command — generate, build, then the package list it already
uses — passes 19 packages, exit 0.
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
hanzokv/go v9.22.0 renames its Go package from `redis` to `kv` (import
path unchanged). Follow that through the fork so there is one vocabulary
for the key-value bus:
- bus_redis.go -> bus_kv.go, bus_redis_test.go -> bus_kv_test.go,
bustest/redis.go -> bustest/kv.go
- redisMessageBus -> kvMessageBus, and the same for its subscription,
sublist, write-op, publish-queue and bustest server types
- psrpc.NewRedisMessageBus -> psrpc.NewKVMessageBus,
bus.NewRedisMessageBus -> bus.NewKVMessageBus
- log messages and README say kv
The dockertest image stays `redis:latest` and the pipelining doc link
stays on redis.io: those name third-party artifacts, not our types.
Co-authored-by: Hanzo Dev <[email protected]>
PSRPC for Hanzo LiveKit, forked from livekit/psrpc (Apache-2.0). Two rewrites:
github.com/livekit/psrpc -> github.com/hanzoai/psrpc
github.com/redis/go-redis/v9 -> github.com/hanzokv/go/v9
psrpc's message bus (bus.go, internal/bus/bus_redis.go, internal/bus/bustest)
speaks to a KV over go-redis. After hanzoai/livekit moved to our client, psrpc
was the one remaining edge pulling upstream go-redis into that binary — not our
code, but our dependency, the same shape redsync had for hanzoai/git.
The other livekit/* modules (protocol, mediatransportutil, mageutil) are NOT
forked and should not be: none of them touch a KV client, so they are ordinary
external dependencies and their names are addresses.
* deps: bump dependencies (go get -u) and migrate dockertest v3 -> v4
Sweeps go get -u ./... and bumps dockertest to v4, the only direct dep
that needed an explicit major version bump. Migrates the 4 testutils
helpers in internal/bus/bustest/ to v4 (Pool/Resource are now interfaces;
NewPool/Run/Retry take ctx; RunWithOptions replaced by builder; Purge
replaced by ClosableResource.Close).
Other direct deps with newer majors available: none. +incompatible deps:
twitchtv/twirp v8.1.3 (upstream choice, no module-aware path published).
* client: use NewErrorFromResponse for the wire-derived error path
Passes res.Code/res.Error/res.ErrorDetails straight through instead of
round-tripping through NewErrorf, which also resolves the Go 1.25 vet
complaint about a non-constant format string. Plus the previous form
silently dropped error details.
* bump version
* Use redis pipeline to deal with longer latency connections to Redis.
- Using hashed publish queue (probably not super helpful as RelaySignal
probably overwhelms others)
- Use `Pipeline`. Can potentially use `TxPipeline`, but that block other
pipeline clients while it is executing. In tests though (trying to
start 200 rooms with 200ms latency to redis server), the performance was
comparable, i. e. all the rooms were created, but participant join
needed some retries in some runs. In some other runs, participant join
also worked without retries for that setting.
- Execute pipeline immediately (on a publish) and let the RTT processing
opportunistically build up commands for the next pipeline execute.
Maybe, it is possible to run each execute in a separate goroutine to
handle cases of channels like RelaySignal running multiple in parallel,
but ordering could cause subtle issues.
* clean up
* tidy
* add slack notifier
* comment pipeline usage
* add support for wildcard nats topics
* disambiguate topicless server rpc channels and client channels
* cleanup
* cleanup
* channel format
* cleanup
* split queue subs
* cleanup
* move queue flag
* send local router channel in envelope
* test
Add an optional GetRetryParameters function member to RetryOptions. When defined, this will be called before each retry attempt and allow specifying whether to retry, the timeout, and a duration to wait before retrying.
Also add a simple unit test for the retry middleware.
zooqueen
zeekayandHanzo Dev