It is not possible to achieve this reliably and in a performant way (I already stumbled on this a few times unfortunately). I think we should document this for v3 and maybe add a better API in v4.

We could support a factory option that will run for each request?

fastify.decorateRequest('array', function() { return [] }, { factory: true })

That'd slow things down considerably. Moreover, we have hooks for this kind of work and it's as is as adding an onRequest hook. Now, we could have the factory: true option to do all the boilerplate for us (using 'onRequest').

IMO this issue is really important. The circumstance that the instance is shared across requests is very confusing. This provides room for memory-leaks as shown above. I'd always prefer correctness over absolute speed. @mcollina do you mean that fastify.decorateRequest('array', []) register a shared onRequest hook to reset the data?

i'd assume that :

fastify.decorateRequest('array', function() { return [] }, { factory: true })

will result in subsequent

 const fn = function() { return [] };
  function onRequest (request, reply, done) {
    reply.array = fn()
    done()
  }

The problem is that we can't know how to creat a new instance identical to the value as can be of any custom type or class... and the only solution would be an unreliable (and slow) deep copy.

I think we should deprecate decorateRequest(prop, value) with any value that is not null or undefined. There is really no valid use case for that.

We could potentially add a new API that allows to set a factory for the instance value, but this is already covered by hooks.

I think we should deprecate decorateRequest(prop, value) with any value that is not null or undefined. There is really no valid use case for that.

Defaulting to an empty string is totally valid. Really, any primitive is valid. Why do you say it isn't?

Right! All value types are good, including functions. It's really objects, arrays, set and maps that are problematic.

It's really objects, arrays, set and maps that are problematic.

Agree on emitting a warning per these types

Hello, I want to attempt to tackle this issue. Please let me know if this issue no longer needs assistance.

Sure!

Could you target the next branch?

How do you plan to solve this?

What's left here?

We now emit a warning if an object is decorated, and others have said complete encapsulation will hurt performance

Though I must admit I like the idea of knowing for sure that a completed request is gotten rid from memory, feels safer 😄