Skip to content

Conversation

@WyriHaximus
Copy link
Contributor

No description provided.

default => new Response(404, [], 'Error 404'),
};
}))->catch(
static fn (Throwable $error): PromiseInterface => resolve(Response::plaintext($error->getMessage())->withStatus(200)), // This should be a 500, but with a 200 the benchmarking tooling considers the framework alive
Copy link
Contributor

@joanhey joanhey Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's OK to send a 500 response to the tests.
The problem is in React or the code. The app is blocked again when send a 500.
Also end stuck when send a 400 or 404.
I said it to fix the root of the problem.

You can check it with the plain PHP files, and send a 500 error, the tests will continue normally and the tests fail normally. Never show reactphp: ERROR: Framework is not accepting requests from client machine.

Copy link
Contributor

@joanhey joanhey Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also update your local repo, because my PR is included now, and the db tests are disabled.
So never will arrive to this catch().

So this PR need to include again the tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if any test fail, never will be merged !!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's OK to send a 500 response to the tests.

Sure, I don't doubt that. But it's not during the liveness check. As per https://explainshell.com/explain?cmd=curl+--fail

The problem is in React or the code. The app is blocked again when send a 500. Also end stuck when send a 400 or 404.

Actually, it is not, you made a very conscious decision not to allow any status of 400 and high to be considered ready for benchmarking with #3709. So the problem is in the design that checks an arbitrary endpoint to see if the entire application is ready rather than the one with the least complexity and dependencies on other services that could cause issues.

I said it to fix the root of the problem.

I can do that by creating a PR that drops the --fail flag, but you've been very strongly opposed to any changes to the toolset.

You can check it with the plain PHP files, and send a 500 error, the tests will continue normally and the tests fail normally. Never show reactphp: ERROR: Framework is not accepting requests from client machine.

Again tests I don't doubt that, but for the reasons mentioned about you've purposely blocking 500's

Also update your local repo, because my PR is included now, and the db tests are disabled. So never will arrive to this catch().

So this PR need to include again the tests.

Just did that.

But if any test fail, never will be merged !!

Yes, you've made that very clear on several occasions now.

Copy link
Contributor

@joanhey joanhey Jan 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@WyriHaximus good catch with the --fail in #3709

I'm strongly opposed to any unilateral change in the toolset, like you did.
Your change to use "plaintext" will fix the problem with React, but will break hundreds of frameworks variants.
When a framework variant test for another db, only create the db endopints, so it'll fail to check the "plaintext".
Also a change in the toolset, need to test all the frameworks with the Github actions, that is a very long time, and always will fail with some frameworks.

Please create a issue for this change, and I'll support it.
So all the devs can discus it and the people from Techempower will decide what to do.
I think that remove that --fail don't need to much discussion, but also we need to check if it's breaking a lot of frameworks.

PD: I'm not affiliated to Techempower in any way

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@WyriHaximus good catch with the --fail in #3709

I'm strongly opposed to any unilateral change in the toolset, like you did. Your change to use "plaintext" will fix the problem with React, but will break hundreds of frameworks variants. When a framework variant test for another db, only create the db endopints, so it'll fail to check the "plaintext". Also a change in the toolset, need to test all the frameworks with the Github actions, that is a very long time, and always will fail with some frameworks.

Please create a issue for this change, and I'll support it. So all the devs can discus it and the people from Techempower will decide what to do. I think that remove that --fail don't need to much discussion, but also we need to check if it's breaking a lot of frameworks.

Will do, and as you mention that change will affect every framework in here. So will think about it for a while before filing it.

PD: I'm not affiliated to Techempower in any way

Honestly, that doesn't matter to me. You're responding to all my PR's and comments with suggestions or context. Techempower affiliation isn't required there for me. In fact, I even appreciate it that you are spending this much time help out on this project <3.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want I can create the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want I can create the issue.

Won't stop you, but to me #9528, and dropping the --fail flag added through #3709 (which as added for good reasons) are a means to an end. And I rather open an issue with the reasoning for doing those as this makes it less of an X/Y problem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know more this bench, and I understand you.
But it'll be easier for me !!!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both are fine with me, if you do please ping me and I'll put my thoughts in there 👍 .

@WyriHaximus WyriHaximus force-pushed the reactphp-handle-uncaught-errors branch from 3014f1f to 4541529 Compare January 16, 2025 21:10
@msmith-techempower
Copy link
Member

Where does this one stand? Ready to merge or waiting on changes?

@joanhey
Copy link
Contributor

joanhey commented Jan 20, 2025

Ready to be merged!!
But the toolset have a problem, and I'll open a issue.

@msmith-techempower msmith-techempower merged commit 27012ed into TechEmpower:master Jan 20, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants