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

set-cookie semantics should be respected when the request succeeds in the HTTP/2 layer but the GRPC status code is non-"OK". #228

Open
vikt0r0 opened this issue Mar 6, 2023 · 0 comments
Labels
good first issue Good for newcomers [Prio] Low Should be fixed if time permits but can be postponed. [Type] Change Request Some visible functionality should be change.

Comments

@vikt0r0
Copy link
Contributor

vikt0r0 commented Mar 6, 2023

Description
We currently rely on load balancers and set-cookie semantics to ensure that subsequent requests made by the client in a single command invocation arrive at the same node.

However, this is currently only done when the GRPC status code is "OK". However, even if the GRPC response carries a non-"OK" status code, set-cookie semantics should ideally be respected, since nothing precludes subsequent requests to be made in the wake of a non-"OK" GRPC status code.

Note that this is currently not the case, so this currently does not have any implications as the client always fails when a non-"OK" response is returned and thus no subsequent requests are ever made. Thus may be changed in the future, however. Therefore this should be considered a low-priority issue.

@vikt0r0 vikt0r0 added the [Type] Change Request Some visible functionality should be change. label Mar 6, 2023
@vikt0r0 vikt0r0 changed the title set-cookie headers should be handled when the request succeeds in the application layer but the GRPC status code is non-"OK". set-cookie semantics should be respected when the request succeeds in the HTTP/2 layer but the GRPC status code is non-"OK". Mar 6, 2023
@vikt0r0 vikt0r0 added good first issue Good for newcomers [Prio] Low Should be fixed if time permits but can be postponed. labels Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers [Prio] Low Should be fixed if time permits but can be postponed. [Type] Change Request Some visible functionality should be change.
Projects
None yet
Development

No branches or pull requests

1 participant