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

XREADGROUP from PEL should not affect server.dirty #13251

Merged
merged 1 commit into from May 6, 2024

Conversation

guybe7
Copy link
Collaborator

@guybe7 guybe7 commented May 6, 2024

Because it does not cause any propagation (arguably it should see the comment in the tcl file)

The motivation for this fix is that in 6.2 if dirty changed without propagation inside MULTI/EXEC it would cause propagation of EXEC only, which would result in the replica sending errors to its master

Because it does not cause any propagation (arguably it should see the comment in the tcl file)

The motivation for this fix is that in 6.2 if dirty changed without propagation inside MULTI/EXEC it
would cause propagation of EXEC only, which would result in the replica sending errors to its master
@guybe7 guybe7 merged commit 0e1de78 into redis:unstable May 6, 2024
13 checks passed
sundb added a commit that referenced this pull request May 14, 2024
…SP3 in MULTI (#13255)

This test was introducted by #13251.
Normally we auto transform the reply format of XREADGROUP to array under
RESP3 (see trasformer_funcs).
But when we execute XREADGROUP command in multi it can't work, which
cause the new test failed.
The solution is to verity the reply of XREADGROUP in advance rather than
in MULTI.

Failed validate schema CI:
https://github.com/redis/redis/actions/runs/9025128323/job/24800285684

---------

Co-authored-by: guybe7 <guy.benoish@redislabs.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants