[lx3133584]

Problem

When cookies are set on reply using reply.setCookie() or reply.cookie(), there is no way to inspect or read response cookies from reply.cookies within the handler or preSerialization hooks. Although TypeScript types declare cookies: { [cookieName: string]: string | undefined } on FastifyReply, accessing reply.cookies at runtime evaluates to undefined.

Root Cause

@fastify/cookie only registered fastify.decorateRequest('cookies', null) on the request object. It did not define a getter for reply.cookies on the reply instance to expose the staged cookies from the internal kReplySetCookies map.

Fix

Add a reply.cookies decorator getter that returns an object mapping cookie names to their respective values from the staged response cookies map, matching the TypeScript type definition and enabling synchronous inspection of set cookies before onSend.

Testing

• Added unit tests in test/cookie.test.js verifying reply.cookies returns set cookies and defaults to an empty object.
• Added type test in types/index.tst.ts verifying type resolution on reply.cookies.

[Fdawgs]

@lx3133584 This is incredibly similar to your other PR #372

[Fdawgs]

@lx3133584 Please comment on above. No response will lead to this and the rest of your PRs being closed and blocked as this smells of just firing an AI at the repo with zero understanding.

[lx3133584]

Apologies for the confusion and noise! You're completely right — both PRs target the same underlying use case (inspecting staged response cookies on the reply before onSend), but explored two different API styles:

1. feat: add reply.getCookie and reply.getCookies methods #372 adds method accessors (reply.getCookie(name) / reply.getCookies()), matching Fastify's standard reply.getHeader() / reply.getHeaders() pattern.
2. feat: expose cookies getter on reply to access response cookies #375 used a getter property reply.cookies, mirroring request.cookies.

Having both open at the same time was redundant on my part. Since Fastify core idioms favor method accessors (getHeader/getHeaders), #372 is the more idiomatic approach. Closing this PR now to keep all feedback and discussion consolidated on #372.