What

hasRequestDecorator and hasReplyDecorator only check the constructor prototype and the decorator props list. But several core properties — req.id, req.params, req.raw, req.query, req.log, req.body, reply.raw, reply.request, reply.log — are assigned directly in the Request and Reply constructors, not on their prototypes.

This means:

fastify.hasRequestDecorator('id')   // returns false (wrong)
fastify.decorateRequest('id', null) // silently succeeds (wrong)
// then at request time:
// TypeError: Cannot set property id... or req.id is null

Root cause

checkRequestExistence and decorateConstructor in lib/decorate.js use Object.hasOwn(prototype, name) and name in prototype. Properties set in the constructor body are never on the prototype, so these checks miss them.

Fix

Add an instanceProperties set to Request and Reply listing their constructor-assigned string-keyed properties. decorateConstructor and the checkRequest/ReplyExistence helpers now also check this set (walking the parent chain for derived constructors).

After the fix:

fastify.hasRequestDecorator('id')     // true
fastify.hasReplyDecorator('raw')      // true
fastify.decorateRequest('id', null)   // throws FST_ERR_DEC_ALREADY_PRESENT
fastify.decorateReply('raw', null)    // throws FST_ERR_DEC_ALREADY_PRESENT
fastify.decorateRequest('myExtra', null) // still works fine

All 52 existing decorator tests pass. Six new node:test tests cover the bug and the fix.