Hi @rela589n,

Thanks for submitting this bug report. I tried out your test case and I can confirm the same bug is happening for Symfony version 6.3.4 and that the fix you suggested indeed makes the test case pass. I'm not sure whether this bug is necessary to fix since TraceableStack is marked as Internal, however, StackInterface does explicitly mention that all implementations must be cloneable, so it's likely this should be fixed.

In terms of the potential fix, I would also suggest cloning $stopwatch as well as it may have the same issue:

public function __clone(): void
{
    $this->stack = clone $this->stack;
    $this->stopwatch = clone $this->stopwatch;
}

Here's my reproduction of the test case including the potential fix (which causes it to pass): krciga22@9c71a0e

By the way, since TraceableStack is marked as Internal, I'm curious if you are utilizing it for Symfony development or for a separate project that utilizes Symfony framework and/or components?

Status: Reviewed

@krciga22 the Stopwatch must not be cloned, otherwise the traced timing won't be registered in the profiler due to registering them in a different Stopwatch.

@stof makes sense, I didn't realize that. TraceableStack is given a Stopwatch to use on construction and isn't expected to own/manage it, so it has no right to clone it.

Hi, @krciga22 ,
Thanks for the reply, I highly appreciate it

By the way, since TraceableStack is marked as Internal, I'm curious if you are utilizing it for Symfony development or for a separate project that utilizes Symfony framework and/or components?

I'm currently working on project built with Symfony framework. It has its own micro-framework built with Messenger component inside primarily used for cross-layer communication. Basically this is just a command bus with some additional middlewares providing common features for our specific needs.

The implementation of one more middleware required a source stack to be cloned. When running in prod mode everything worked fine, while running in dev-mode causes bug, since TraceableStack wrapper is added.

Current implementation uses following workaround for TraceableStack:

$closure = fn (): object => $this->stack = clone $this->stack;
$closure->call($stack);

It would be great if this bug was fixed so that we won't have to write dirty workarounds.

I see, definitely sounds like a plausible scenario that might occur when writing different middleware. I've worked on the fix for this based off of your suggested fix and will try to create a PR for it tonight.

In case you or @stof have any suggestions before I submit a PR, here's my latest commits: 6.4...krciga22:symfony:issue-51564

One thing I'm not sure of though is the line with class_exists(TraceableMiddleware::class);. I'm not sure if there's a better way to import the TraceableMiddleware class since it's in the same file as TraceableStack?

it should be inside the test at least, not at top-level

@stof , good call I thought there was something else funny about that line. I've gone ahead and updated the test as well as refactored it to (I hope) more accurately test that the cloned TraceableStack unstacks independently. I've also added another test to specifically test that the same Stopwatch is used by the clone and the original.

6.4...krciga22:symfony:issue-51564