-
Notifications
You must be signed in to change notification settings - Fork 774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partially fix #3160 by properly handling resultsFormat query #5917
Conversation
🦋 Changeset detectedLatest commit: 41624d9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-wrangler-5917 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/5917/npm-package-wrangler-5917 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-wrangler-5917 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-create-cloudflare-5917 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-cloudflare-kv-asset-handler-5917 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-miniflare-5917 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-cloudflare-pages-shared-5917 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/9256924792/npm-package-cloudflare-vitest-pool-workers-5917 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
This PR fixes cloudflare#3160 caused by ignoring the `resultsFormat` query that `workerd` sends. The commits add proper handling of the query. It makes `raw` preserve columns with the same name by handling `resultsFormat=ROWS_AND_COLUMNS` and removes `results` from `run` as it sends `resultsFormat=NONE` (see https://github.com/cloudflare/workerd/blob/1d89f3b8e9cdcd898ea486656d72d9551e79f4a3/src/cloudflare/internal/d1-api.ts#L295)
@geelen @petebacondarwin please take a look again. I found the root cause of the problem and fixed the issue. I bealive it's a critical bug as it breaks people code in unexpected way and creates an impression of D1 as unreliable product that might behave differently in production. I'm confident in the fix quality, so I think it won't create much work for you and fix an important problem for customers. |
This PR fixes cloudflare#3160 caused by ignoring the `resultsFormat` query that `workerd` sends. The commits add proper handling of the query. It makes `raw` preserve columns with the same name by handling `resultsFormat=ROWS_AND_COLUMNS` and removes `results` from `run` as it sends `resultsFormat=NONE` (see https://github.com/cloudflare/workerd/blob/1d89f3b8e9cdcd898ea486656d72d9551e79f4a3/src/cloudflare/internal/d1-api.ts#L295)
Sorry, looks like the build is failing - can you run prettier against |
nvm found the issue, missing |
@rozenmd sorry, I had to turn off automatic formatting as it was changing unrelated files, particularly in |
That's alright @kossnocorp - I can fix it up |
@rozenmd thank you, I appreciate it! |
Looked at this a bit more - can you remove this part?
We initially released this change in workerd and had to rapidly roll-forward a fix in our D1 Worker to prevent breaking compatibility with user Workers that relied on |
@rozenmd sure, I'm on it. |
@rozenmd done! |
|
||
// Check whether workerd raw test case passes here too | ||
// Note that this test did not pass with the old binding | ||
if (!t.context.bindings["__D1_BETA__DB"]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test suite is dynamic (yay) and gets run by both versions of the D1 binding.
I had to add this check to ensure that it's fixed only for new bindings (since old versions of wrangler have the old binding, and we have no control over that code)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fascinating!
@rozenmd thank you for helping me to land this PR into the main branch 🙏 |
TL;DR: Cloudflare D1 has a critical bug in Workers SDK reproducible on the Cloudflare D1 Console and when running D1 through Wrangler. The PR fixes the bug and also improves compatibility with
workerd
.The problem
The essence of the problem is selecting two columns with similar names:
...must return in the row containing both columns (tested on PostgreSQL v16.3):
SQLite (on a database created by Wrangler) gives a similar result:
I also added a test for this behavior to workerd that is passing:
However, when sending the same request through Workers SDK, I get:
As both columns have the same name,
name
, they got squashed into a single column.A GitHub user raised the issue a year ago and since then it got fixed in
workerd
(that my test confirms), but it is still present in Workers SDK.The problem is also reproducible in Cloudflare D1 Console, where I get the same data:
It breaks people's code in unexpected ways and creates an impression of D1 as an unreliable product that might behave differently in production.
In my opinion, it's a critical bug that must be prioritized.
The source
I chased the bug through
wrangler
→workerd
→miniflare
to these line indatabase.worker.ts
:When running the test:
...the
cursor
object passed throughall
results in the given structure:You can see that at this point, the information is already lost, and the
name
columns have been reduced to one property.After further researching I found that
workerd
sends theresultsFormat
query that determines the format of theresults
.It worked before only because
workerd
handles the case when the API always returns an array of objects either by sheer luck or as a workaround for Workers SDK behavior.The solution
The PR fixes the problem and adds proper handling of the
resultsFormat
query.It makes
raw
preserve columns with the same name, addressing the original problem.It also adds handling of
NONE
whichworkerd
sends withrun
andexec
(hence the change in existing test cases).Extras
Here's the SQL I used to test the behavior:
What this PR solves / how to test
The PR fixes #3160.
Author has addressed the following