how to debug "error: handle worker: error read frame: unexpected frame type 47" error message...

[mcarbonneaux]

i've delopped spoa program that work fine on docker/podman use case.
i've deployed in kubernetes environement, and now each 10s i receive this error : "error: handle worker: error read frame: unexpected frame type 47"

i've try to add http port to implement liveness/readyness and configured deploymentset to use this port...
and continue de send error message...
when i remove the kubernetes services no more error.
i think that kubernetes services try to connect every 10s event if no liveness are configured.

there is possibility to simply ignore tcp connect check ?

i think is her:

haproxy-spoe-go/frame/read.go

Line 32 in 042087d

return fmt.Errorf("unexpected frame type %d", f.Type)

[mcarbonneaux]

in fact type 47 arrive when the loadbalancer try to do http check on spoe port....

[gfeyer]

Right, it's the LB's HTTP probe — and the reason it's specifically type 47 is just that 47 is /. SPOP's frame header is 4 bytes of length + 1 byte of type, so GET gets eaten as the length and / lands on the type byte:

An SPOP frame header is 5 bytes: a big-endian uint32 length, then a 1-byte type.
When an HTTP probe sends GET / HTTP/1.1\r\n…, the agent reads those first 5 bytes as:

byte	hex	ASCII
0	0x47	G
1	0x45	E
2	0x54	T
3	0x20
4	0x2F	/

So Len = 0x47455420 (~1.2 GB) and Type = 0x2F = 47. The early reject in frame/read.go:32 exists specifically to drop that frame before allocating a 1.2 GB read buffer — it was added in v1.0.2 (fix-oom-on-http-requests, #9) after exactly this kind of stray HTTP traffic OOM'd the agent. So the error message you're seeing is actually good; the connection is closed cleanly right after the log line.

The fix belongs on the Kubernetes side, not in the library — the SPOP port speaks a binary protocol, so it can't answer HTTP probes. Two options:

1. Switch the probe to TCP, not HTTP. A plain TCP connect+close hits io.EOF in frame.Read, which the worker already treats as a clean close (worker/worker.go:125-134) — no log line at all. Make sure the cloud LB's health check is configured as TCP against the SPOP port, not HTTP (e.g. AWS NLB defaults to TCP; ALB does HTTP and is the wrong fit here). For pod-level probes, use tcpSocket: instead of httpGet:.
2. Probe a different port. Expose your existing HTTP liveness/readiness endpoint on a separate containerPort, and point both the kubelet probes and the LB health check at that port — never at the SPOP port.

I think fixing the probe is probably the right thing to do

[gfeyer]

cc: @negasus in case you want to verify my analysis above, but am pretty confident that's the reason