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

State stores: conformace test to check special characters are not mangled #2910

Closed

Conversation

JoshVanL
Copy link
Contributor

@JoshVanL JoshVanL commented Jun 13, 2023

Conformance test for all state stores to ensure that all state stores are able to store and return keys who's values are string which contain special characters.

Adds new state/utils.JSONStringify function for converting a []byte into a jsonified []byte string. Update state stores which were incorrectly encoding special characters in string state values on set.

Question: Why are we doing anything to Values when Setting to state stores? Why do we not Set them as-is?

strings, written as is

Signed-off-by: joshvanl <me@joshvanl.dev>
@JoshVanL JoshVanL requested review from a team as code owners June 13, 2023 14:49
Signed-off-by: joshvanl <me@joshvanl.dev>
@JoshVanL JoshVanL force-pushed the test-conformance-state-specical-characters branch from 2848d3a to a7ccf78 Compare June 13, 2023 15:33
JoshVanL and others added 9 commits June 14, 2023 14:07
Signed-off-by: joshvanl <me@joshvanl.dev>
Signed-off-by: joshvanl <me@joshvanl.dev>
Signed-off-by: joshvanl <me@joshvanl.dev>
Signed-off-by: joshvanl <me@joshvanl.dev>
Signed-off-by: joshvanl <me@joshvanl.dev>
`JSONStringify`

Signed-off-by: joshvanl <me@joshvanl.dev>
Signed-off-by: joshvanl <me@joshvanl.dev>
Copy link
Contributor

@ItalyPaleAle ItalyPaleAle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I am concerned with: is this going to cause backwards-incompatibility?

  1. What about reading values created with Dapr "vCurrent" using "vNext"?
  2. What about reading values created with Dapr "vNext" into "vCurrent"?

state/utils/utils.go Outdated Show resolved Hide resolved
}
}

// Deprecated: use JSONStringify instead.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be deleted then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is still references in dapr/dapr. We can remove once we have merged this, updated go mod and migrated the caller in dapr/dapr

for _, o := range request.Operations {
switch req := o.(type) {
case *innerSetRequest:
store.doSet(ctx, req.req.Key, req.data, req.ttl)
err = errors.Join(err, store.doSet(ctx, req.req.Key, req.req.Value, req.ttl))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the errors.Join here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are inside a range, and want to catch all doSet errors.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However this is not really how errors.Join should be used, as the Go team told me too: golang/go#60209
Should collect the errors in a slice and then call errors.Join once

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 👍

@artursouza
Copy link
Member

What I am concerned with: is this going to cause backwards-incompatibility?

  1. What about reading values created with Dapr "vCurrent" using "vNext"?
  2. What about reading values created with Dapr "vNext" into "vCurrent"?

This is a common debate of fixing a bug but having customers relying on the bug. We do have a way to workaround that, it is to bump the component version and keep the old version untouched. It would require to copy and paste the code and deprecate v1 of each component that has a breaking change.

@ItalyPaleAle
Copy link
Contributor

Even if we made a "v2", something I would consider a last-resort as it would double the maintenance burden on maintainers of this repo, we also need a solution for data that was already written. Otherwise, users (who, on average, never read docs, let alone changelogs ) will just switch "v1" to "v2" and then complain Dapr broke their data 🙃

@JoshVanL what are the "broken" components in 1.11.0?

@ItalyPaleAle
Copy link
Contributor

Some additional interesting findings. The interface in components accepts data as any, so I was wondering what kind of data actually gets stored from Dapr.

  1. When data comes from the gRPC API, it's always received by the component as a []byte. Some components base64-encode that before storing it.
  2. When it comes from HTTP, it's whatever it is in the JSON that it's received. For example, if you pass a number, it's a float64 (because JavaScript...), strings are strings, bools are bools, and objects/arrays are received by the component as-is so are serialized as JSON.

This seems like it can cause a lot of inconsistencies also depending on how the data is stored and retrieved.

Perhaps the problem isn't really having a v2 of components, but a v2 of the state store APIs that removes all these inconsistencies...

state/utils/utils.go Outdated Show resolved Hide resolved
JoshVanL added 2 commits June 15, 2023 11:51
Signed-off-by: joshvanl <me@joshvanl.dev>
Signed-off-by: joshvanl <me@joshvanl.dev>
@JoshVanL
Copy link
Contributor Author

@ItalyPaleAle I believe these would have been the broken ones https://github.com/dapr/components-contrib/actions/runs/5257496485

@ItalyPaleAle
Copy link
Contributor

List here:

image

Aside from in-memory which doesn't matter, I am very surprised to see MariaDB in the list but not MySQL, since they should be the same...

@ItalyPaleAle ItalyPaleAle added the do-not-merge PR is not ready for merging label Jun 15, 2023
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot added the stale label Jul 15, 2023
@github-actions
Copy link

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot closed this Jul 22, 2023
@yaron2 yaron2 reopened this Jul 22, 2023
@github-actions github-actions bot removed the stale label Jul 22, 2023
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot added the stale label Aug 21, 2023
@github-actions
Copy link

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot closed this Aug 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge PR is not ready for merging stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants