in this case the transactions to write were likely overlapping. Spicedb postgres will see the data for: "all transactions that were complete before my transaction, and my transaction's mutations", which fully explains the behavior that you're seeing

we decided to fix it in the following way - in case we have consecutive write and read requests we will pass the zedToken from write request response inside read request

right, and that should work if they are isolated userflows, i.e. if the read only needs to read the writes of the write preceeding it, and not all other writes that may have happened on the system concurrently, or what we refer to as the "read your own writes" scenario

where "immediate" is the same as "fully consistent?"

yes