Updated rows from batch should not be aggregated

[lukaseder]

Bug Report

Versions

• Driver: 0.9.0.M2
• Database: PostgreSQL 13.2 (Debian 13.2-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
• Java: OpenJDK Runtime Environment (build 17-ea+31-2664)
• OS: Microsoft Windows [Version 10.0.19043.1165]

Current Behavior

When running a batch with more than N statements, I would expect the driver to continue producing N update counts. However, it seems the driver now aggregates the update counts and produces only a single value.

Table schema

create table t (i int);

Steps to reproduce

System.out.println(
    Flux.from(cf.create())
        .flatMap(c -> c.createBatch()
            .add("insert into t values (1),(2)")
            .add("insert into t values (3)").execute())
        .flatMap(it -> it.getRowsUpdated())
        .collectList()
        .block()
    );

The output is [3]

Expected behavior/code

The expected output is [2, 1] (or [1, 2] if the sequence order cannot be maintained)

Additional context

Would be good to add expectations in the TCK for this behaviour to document it for other drivers:
https://github.com/r2dbc/r2dbc-spi/blob/47e25176a1e94736c004d20cd04315b463ddc289/r2dbc-spi-test/src/main/java/io/r2dbc/spi/test/TestKit.java#L292-L308

[mp911de]

This is a known limitation introduced with #401. The root cause is a weird behavior of the windowUntil operator that allows creation of substreams. In the context in which we used windowUntil, the demand dropped to zero and no frames were read from the connection. To avoid lockup we no longer split results into individual Result objects until the issue is fixed. That's a good opportunity to reach out to @simonbasle from the Reactor team.

[Squiry]

I think I should have provided an issue to Reactor project, but I forgot. Reproducer is here.

[mp911de]

Paging @simonbasle @OlegDokuka to sort out the windowUntil issue. You can find a reproducer at https://gist.github.com/mp911de/9b99e10f0e1211cd9d5d3fd1dd9479eb

Note that Reactor 3.3 can reproduce the issue while 3.4.9 seems fixed.

[OlegDokuka]

Paging @simonbasle @OlegDokuka to sort out the windowUntil issue. You can find a reproducer at https://gist.github.com/mp911de/9b99e10f0e1211cd9d5d3fd1dd9479eb

Note that Reactor 3.3 can reproduce the issue while 3.4.9 seems fixed.

We have done a couple of improvements in the few recent releases of 3.4.x, but we can see if those couled be back ported if these is critical for 3.3.x users

[mp911de]

That would be good to have it in 3.3.x as a few features are blocked by this issue.

[simonbasle]

That would be good to have it in 3.3.x as a few features are blocked by this issue.

@mp911de do we still need to backport the changes in windowUntil from 3.4.x to 3.3.x ?
If so, can you open an issue in reactor-core so that we can track?

[mp911de]

Yes, the backport is needed, i filed reactor/reactor-core#2783.

[mp911de]

For the time being, I added a reflective guard to check when the driver is being used with Reactor 3.4, that we use windowUntil(…) as that is a safe operation.

[OlegDokuka]

Paging @simonbasle @OlegDokuka to sort out the windowUntil issue. You can find a reproducer at gist.github.com/mp911de/9b99e10f0e1211cd9d5d3fd1dd9479eb

Note that Reactor 3.3 can reproduce the issue while 3.4.9 seems fixed.

Can you please try the same with reactor 3.3.19+. I just realized that we have them backported in exactly this version. 3.3.17 does not have them yet

[mp911de]

Thanks a lot. For some reason, we were stuck at Reactor 3.3.17. Reactor 3.3.20 no longer reproduces the issue.