Oleksii Sholik

@icehaunter any comments?

@davidmartos96 I have pulled your changes into my branch and opened a new PR based on that - https://github.com/electric-sql/electric/pull/1334. Thanks for the contribution!

> A bit on topic with the pings, we found an odd behavior with the inactive websocket disconnection. I reported it the other day on Discord, but I don't know...

@nurturenature Thanks a lot for sharing these results! We'll be taking a closer look at the anomalies.

I have traced the origin of the `"true"` value to this place in `LogicalReplicationProducer` module's implementation: ``` defp process_message( %Message{transactional?: true, prefix: "electric.fk_chain_touch", content: content}, state ) do received =...

Hey @marksteve :wave: Looks like you're using the new client API but it's connecting to `localhost`. Are you working with self-hosted Supabase?

@marksteve So have you tracked the hanging of the proxy to Supabase blocking your IP? Did you managed to generate a client after rerunning `npx electric-sql generate`?

> @alco Nope. The proxy is connected to hosted Supabase. Side note: Took me a while to notice but there were times my IP got blocked by Supabase. Something that...

@justindotpub We will support passthrough for DO...END blocks one way or another. We just haven't come up with a satisfactory design for it yet. You can work around this limitation...

The same problem is present in the `SatOpLogAck` message. The protocol definition for this message defines the `additional_data_source_ids` field: https://github.com/electric-sql/electric/blob/0115a0a345c86b1677b997a79f4325ab1ed32b80/protocol/satellite.proto#L245-L246 However, on the client, `move_in_ref`s from `SatOpAdditionalCommit` messages are used...