Calling `getCookie(c, 'key')` after `setCookie(c, 'key')` results in old data

[NamesMT]

Not sure if this should be considered a bug or feature request, but would be great if we have something that can get the latest data after setCookie, it would help a lot to implement things like session managers, and is more intuitive, matching how cookies I/O works on the client.

[yusukebe]

Hi @NamesMT

It's not a bug, it's designed so. This is a simple question. Isn't it enough to call getCookie after setCookie manually?

[NamesMT]

Hi @yusukebe, it is not enough to just call getCookie after setCookie currently, i.e.:

setCookie('k', 'val')
getCookie('k') // Is `undefined`, not `'val'`

[yusukebe]

@NamesMT

Ah, completely misunderstood. Yes. The feature you suggest should be implemented. Can you create a PR to do it?

[IAmSSH]

@yusukebe Is it actually an expected behaviour? I feel the current implementation is correct, because setCookie sets the header attribute on the response headers, while getCookie tries to get cookie from the request, hence the undefined because it is not yet present on the request. If we try to hit the same endpoint that sets the cookie (and prints it) one more time, we'll see that getCookie will print the cookie value since it is now present in the request.

When we set a cookie, we should be setting it on the response, not on the request. Does it actually makes sense to set it also on the request?

[NamesMT]

@IAmSSH Thats why I said not sure if this should be a feature request or bug, technically the current implementation is more correct when thinking as a request/response server, but DX-wise, its a bit not perfect and doesn't match client-side (frontend) cookies I/O.

I think, this issue (and a few related: #4445, #4446, #4447), if implemented, can probably be a new (set of) opt-in util(s), leaving the current utils which is highly optimized for lighter usecases / smaller servers intact.

Consider the issues "Request For Comments" for now.