Thomas Jungblut

okay after debugging this, the implementation of the watch endpoint is a bit odd: https://github.com/etcd-io/etcd/blob/main/api/etcdserverpb/gw/rpc.pb.gw.go#L205-L228 On the grpc proxy the type couldn't be parsed correctly to either Create/Cancel: https://github.com/etcd-io/etcd/blob/main/server/proxy/grpcproxy/watch.go#L233 So...

Thanks @elricli, I think I can reproduce this with a simply curl: > curl -X POST http://localhost:8080/v3/watch -d '{"create_request": {"key":"Lw=="} }' The EOF error comes from the fact that it...

so I tried different languages and doing bidi streaming requests, I can only really make this work while removing the EOF breaking during the send loop: ``` diff --git a/api/etcdserverpb/gw/rpc.pb.gw.go...

Cleaning up all the threads today, this requires somewhat of a decision for etcd. The grpc-gateway does [not support bi-di streaming](https://github.com/grpc-ecosystem/grpc-gateway/issues/2954#issuecomment-1281187913), nor is a correctly working version easy to add....

I've spent some time to move porcupine to generics earlier this week. It also clones the state before invoking the step func, in case you want to get rid of...

Never seen this before.

I started yesterday to fiddle around with [xfstests](https://github.com/kdave/xfstests) to find a way to crash XFS more efficiently. The issue from https://github.com/etcd-io/bbolt/issues/701 certainly also uses XFS.

@fuweid just noticed it as well, I'm writing a couple of xfs tests as an addition to the ones for ext4 as we speak :) will send a PR later....

You're correct, int is 64 bits on a 64 bit system: ``` $ octosql "SELECT 2147483647+2147483647, 9223372036854775807+9223372036854775807" +------------+-------+ | col_0 | col_1 | +------------+-------+ | 4294967294 | -2 | +------------+-------+...

/test pull-etcd-unit-test reported the current failure as flake, otherwise /lgtm (non-binding)