Hey!

I think@fancyweb has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

Hi@Jeroeny and thanks for the PR.
I submitted#43333 instead because I think this would be a more appropriate fix.
Can you please confirm that it also fixes the issue you reported?
About the commands, that's another topic (not a critical one I would say :) )

I submitted#43333 instead because I think this would be a more appropriate fix. Can you please confirm that it also fixes the issue you reported?

Thanks for the help. It seems that with that tag, theTraceableHttpClient is not reset when callingreset on theprofiler service, unfortunately. Is the client expected to be reset when the profiler is reset?

TraceableHttpClient is not reset when calling reset on the profiler

That's correct, but what you want is that TraceableHttpClient is reset when calling reseton the container, which what the tag should do, isn't it?

That's correct, but what you want is that TraceableHttpClient is reset when calling reseton the container, which what the tag should do, isn't it?

Thekernel.reset tag indeed behaves as expected. I'd have liked a way to reset it as part of the DataCollectors, because then I can specifically reset profiling data. With a container reset, things like ArrayAdapter caches are also reset. But I just noticed thatthe messenger reset feature also resets services ofkernel.reset, so it's probably intended this way?

I'd have liked a way to reset it as part of the DataCollectors, because then I can specifically reset profiling data

is that a real world use case? as of now, resetting is supposed to be managed by the container, as resetting only a subset of leaking services makes little sense.

is that a real world use case? as of now, resetting is supposed to be managed by the container, as resetting only a subset of leaking services makes little sense.

It was for debugging a production memory leak, where we'd want to reset the profilers and leave only the memory leaks that shouldn't be there. So that we could better evaluate the production-level leak (which could for example be in a misconfiguredArrayAdapter without a$maxItems).

Though I agree it's a bit of a specific use case. As far as I'm concerned the current setup is fine then, as we have enough options to approach this problem (like running a local environment inAPP_ENV=prod). Thanks 👍