class X {
function __construct(int ...$args) {
//print_r( $args );
}
}
PEAR_Error
?
__destruct
is not called deterministically. I think the destruct is called after laravel resets itself for the next test and then fails because its not in the state the original test expected, I'll keep looking into this to see if this is actually the case though (I can't really reproduce this easily, I'll probably disable the __destruct
for now)
The following psuedo-code is what happens as far as I can tell:
SetupLaravelApplication();
{ // create new scope
$obj = new Command();
}
DestroyLaravelApplication();
In PHP $obj is destroyed at the end of the scope, in C# its destroyed whenever (and from another thread (the finalizer thread)?) so that causes some problems
SetupLaravelApplication();
try { obj = new Command(); }
finally { obj?.Dispose(); }
DestroyLaravelApplication();
BTW sadly, PHP does not have code scopes, only local and global. So it destroys its local variables on the very end of the function block (as I remember)
seems to be correct. It only calls destruct at the end of the function (or when I dereference the last value, for example $obj = new TestClass(); $obj = new TestClass2();
, TestClass destruct will be called here)
Request-Context
header because AppInsights adds one to every response before wpdotnet then adds the one from the original caching request
if (header.Key != "Request-Context") {}
around the re-adding mechanism when serving a cached response