prisma / prisma-engines

🚂 Engine components of Prisma ORM
https://www.prisma.io/docs/concepts/components/prisma-engines
Apache License 2.0
1.19k stars 238 forks source link

[DA] Planetscale engine tests: prisma_17103::regression #4480

Open miguelff opened 11 months ago

miguelff commented 11 months ago

This is a subcluster of failures after having enabled planetscale tests in https://github.com/prisma/prisma-engines/pull/4423

Failing tests in this cluster:

new::regressions::prisma_17103::prisma_17103::regression

Please follow this process

jkomyno commented 5 months ago

Just did a manual run of new::regressions::prisma_17103::prisma_17103::regression, https://github.com/prisma/prisma/issues/17103 still happens on PlanetScale. The original issue is closed, but it only referred to MySQL (we didn't support Driver Adapters back then).

In particular, the test new::regressions::prisma_17103::prisma_17103::regression fails with the following error:

Expected 1 records to be connected after connect operation on one-to-many relation 'AToB', found 0.

jkomyno commented 3 months ago

Update: new::regressions::prisma_17103::prisma_17103::regression fails even when testing it with relationMode = "foreignKeys":

    #[connector_test(relation_mode = "foreignKeys")]
    async fn regression(runner: Runner) -> TestResult<()> {
        run_query!(
            &runner,
            r#"mutation {
            createOneA(data: { id: 1, b: { create: { id: 1 } } }) {
              id
            }
          }
          "#
        );

        insta::assert_snapshot!(
          run_query!(&runner, r#"mutation { updateOneB(where: { id: 1 }, data: { a: { connect: { id: 1 } } }) { id } }"#),
          @r###"{"data":{"updateOneB":{"id":1}}}"###
        );

        Ok(())
    }
jkomyno commented 3 months ago

Update: the problem lies in how the number of affected rows is computed.

When using the mysql Rust driver, we set a special client connection flag, CLIENT_FOUND_ROWS (see PR), which forces MySQL to return the number of rows matching the possibly-implicit WHERE filter in INSERT and UPDATE operations.

Without this, MySQL returns 0 affected row when performing a no-op update, but this breaks the Query Engine expectations when performing nested connects, which expect the update to have had happened already.

Problem: there is no known way of setting client connection flags in PlanetScale. We should reach out to them.