fix: UUID type backward compatibility#2509
Conversation
product-auto-label
Bot
added
size: s
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses a backward compatibility issue with UUID types. The change in src/codec.ts correctly adjusts the type inference for UUID strings, so they are now treated as string instead of unspecified. This is a good fix. The related change in src/transaction.ts simplifies parameter encoding by removing filtering for unspecified types, which is a nice cleanup.
My main feedback is that the change in src/codec.ts will likely break an existing unit test. Please see my specific comment for details on how to update the test to align with the new behavior.
I am having trouble creating individual review comments. Click here to see my feedback.
src/codec.ts (1163-1165)
This change correctly removes the special handling for UUIDs that was causing them to be inferred as unspecified. Now they will be correctly treated as strings, which fixes the backward compatibility issue.
However, this change will likely cause the test 'should determine if the uuid value is unspecified' in test/codec.ts to fail. Please update this test to reflect the new behavior, asserting that a UUID is now inferred as a string.
For example:
it('should determine if the uuid value is a string', () => {
assert.deepStrictEqual(codec.getType(uuid.v4()), {
type: 'string',
});
});
surbhigarg92
force-pushed
the
uuid_fix
branch
from
b1bcd4b to
83bfad3
Compare
product-auto-label
Bot
added
size: m
🤖 I have created a release *beep* *boop* --- ## [8.5.0](https://togithub.com/googleapis/nodejs-spanner/compare/v8.4.0...v8.5.0) (2026-01-22) ### Features * Added OUTPUT_ONLY annotations to create_time and update_time in InternalRange to reflect existing service behavior ([#2505](https://togithub.com/googleapis/nodejs-spanner/issues/2505)) ([1058683](https://togithub.com/googleapis/nodejs-spanner/commit/105868339b1d2b7d7701a6b7591b85e3a1ca4098)) ### Bug Fixes * UUID type backward compatibility ([#2509](https://togithub.com/googleapis/nodejs-spanner/issues/2509)) ([7abb33c](https://togithub.com/googleapis/nodejs-spanner/commit/7abb33ca523b612f171def64c1ceb0cb7d162e82)) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
3 participants
This PR reverts the recent change where UUID-formatted strings were implicitly treated as unspecified (untyped). That change caused regressions for customers relying on UUID-like strings being sent as STRING-typed parameters. This PR restores the default behavior: UUID-formatted strings will now default to STRING, ensuring stability for existing applications.
It fixes #2501
Impact on v8.4.0 Users This change affects users who adopted v8.4.0 and relied on the automatic UUID-to-untyped inference. To correctly send a UUID parameter, you must now explicitly specify the type:
javascript
const [rows1] = await database.run({
sql: "SELECT @value",
params: { value: '550e8400-e29b-41d4-a716-446655440000' },
types: {
value: "uuid" , // Explicitly specifying the type
},
});
Temporary Opt-in Flag To temporarily retain the behavior introduced in v8.4.0 (where UUIDs are treated as unspecified), customers can set the environment variable SPANNER_ENABLE_UUID_AS_UNTYPED=true.
Note: This flag causes a deprecation warning to be emitted and will be removed in a future release.
Recommendation: Customers are strongly encouraged to explicitly specify the type as 'uuid' instead of using this flag.