Skip to content
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

Invalid value for column collection_id in table bsos: Expected INT64. #1055

Closed
pjenvey opened this issue Apr 28, 2021 · 3 comments · Fixed by #1056
Closed

Invalid value for column collection_id in table bsos: Expected INT64. #1055

pjenvey opened this issue Apr 28, 2021 · 3 comments · Fixed by #1056
Assignees
Labels
bug Something isn't working

Comments

@pjenvey
Copy link
Member

pjenvey commented Apr 28, 2021

Per sentry:

https://sentry.prod.mozaws.net/operations/syncstorage-dev/issues/11102490/?environment=release

A database error occurred: RpcFailure: 9-FAILED_PRECONDITION Invalid value for column collection_id in table bsos: Expected INT64.

This began 9 days ago, so it's very likely related to the #1046 refactor.

@pjenvey pjenvey added the bug Something isn't working label Apr 28, 2021
@ethowitz
Copy link
Contributor

I was able to reproduce this locally. Still new to Protobuf and Spanner, but here's what I think is happening. collection_id is an INT64 in the Spanner schema, and if we convert it to a string in the protobuf (which we were doing before), Spanner can convert that string into an INT64. When I wrote the new trait, I converted the collection_id (an i32) to a protobuf Value using the set_number_value(), function, which converts the number to a floating point. I'm guessing that when you try to insert a floating point number into an INT64 column, Spanner assumes you made an error instead of trying to convert it implicitly to an INT64.

This could be resolved by going back to converting the collection_id (and the sortindex and ttl) to a string prior to sending it to the database or by constructing the static Int64Value protobuf types.

@jrconlin
Copy link
Member

Part of the problem is that there are a lot of systems that are trying to be "helpful". There's rust, which does strong typing. There's protobuf, which also does strong typing, but differently. There's Javascript, which is one of the transport layers, which is not strongly typed, and quite less helpful,...

At this point, using declared type and string formatting is probably the safest thing.

@ethowitz
Copy link
Contributor

In the PR I opened, I reverted to converting integers to strings before converting to protobuf values for expediency. I think making the switch to the static protobuf values will require more investigative work (and more substantial changes), so I figured it would be best to get a quick fix into master first. That said, if we think it's worth making the switch over to the static types now, I'm happy to do it 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants