fix: Set FastifyRequest.id type as a string

[samchungy]

Resolves #4993

[Uzlopak]

LGTM

[climba03003]

ID might not be string since it is the output of the generate id function.

[metcoder95]

ID might not be string since it is the output of the generate id function.

On types, we somehow make it explicit that the function should return a string (see); although I agree that we do not force this on runtime.
Shall we consider this "valid" accordingly to the types or do we prefer to not do it until we, at least, force coercion to string for the output of the genReqId?

[Uzlopak]

No runtime validation/casting please. genReqId option for the fastify constructor defines the function as returning a string. So if somebody provides a custom genReqId which is not returning a string, then this violates our "api contract" already.

[metcoder95]

No strong opinion about it, so it SGTM 👍

[gurgunday]

No runtime validation/casting please. genReqId option for the fastify constructor defines the function as returning a string. So if somebody provides a custom genReqId which is not returning a string, then this violates our "api contract" already.

Just wanna +1 this especially when it comes to Fastify since zero overhead is a core principle – that the type definitions are there for a reason and breaking that contract will naturally introduce unexpected behavior, weather it is in the form of errors or something else

[Eomm]

ID might not be string since it is the output of the generate id function.

Correct, but:

• by default it is a string
• if user customizes it, it reads from headers 99% of the times, so it is a string