why does my "newPendingTransactions" geth subscription not get any events?

Question

Im facing the following challenge. I try to subscribe to "newPendingTransactions" via websocket. I can successfully connect to the websocket. When connected, I would expect a stream of new incoming pending transactions, which I can read out and propagate it to some channel (chan json.RawMessage).

...

c, httpResponse, err := websocket.DefaultDialer.Dial(u.String(), req.Header)

...

for {
        messageType, message, err := c.ReadMessage()
        if err != nil {
            log.Println("ERROR:", err)
            os.Exit(1)
            return
        }
        _, _ = message, messageType
        // s.Out is the outgoing chan json.RawMessage
        s.Out <- message
}

...

sadly I dont receive any message (pending tx).. only one on closing the whole construct. When I check on my node directly with "txpool.status" in console, then I can see that there are new pending txs incoming all the time. They just dont wanna get propagated to my websocket connection. Is there anyone who can help me out here? Maybe I am missing a parameter for starting the geth node itself?

here is how I start my geth node:

geth --http.api eth,web3,debug,txpool,net,shh,db,admin,debug --http --ws --ws.api eth,web3,debug,txpool,net,shh,db,admin,debug  --ws.origins localhost --gcmode full --http.port=8545 --maxpeers 120

here is my "admin.nodeInfo":

Geth/v1.10.16-stable-20356e57/linux-amd64/go1.17.5

Answer 1

I found out what I did wrong:

It was not about any forgotten geth parameter and even that the "newPendingTransactions" were propagated correctly..

I tested the websocket connection with another tool called "wscat" and sent the necessary rpc via console (resulting in a stream of tx hashes!)

{"id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}

It showed me that the error must be about the golang code itself..

The last line inside the for loop

s.Out <- message

was sending messages into an unbuffered channel. In order for this to work, some other go routine must consume the channels messages on the other side.

It also helps to use a buffered channel like this:

s.Out = make(chan Message, 1000)

... so at least a 1000 messages will be sent out