Open miguelff opened 11 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.
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(())
}
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 connect
s, 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.
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:
Please follow this process