Please add more information to your issue. Without test instructions and/or any description we will close this issue within 4 weeks. Thanks.
This is an automated message from the J!Tracker Application.

@joomla-cms-bot I added the description for this pull request

This pull request has been automatically rebased to 5.2-dev.

@Chrissi2812 Please provide instructions how to provoke an error which would be cached and how to then test this PR. I would really like to see this in 5.2, but I can't merge it without tests and people wont test it without instructions. Thank you!

Here are some testing instructions:

1 - Create an are article and link it from a menu item
2 - Verify it's showing normally by visiting the link from the menu item
3 - Unpublish the article
3 - Enable the Joomla Cache system plugin
4 - Clear the Joomla cache
5 - Visit the menu item link again: you get a 404 Page not Found error
6 - Publish back the article

Without the change

Any visitor keeps getting a 404 when trying to view that page, despite the article having been published again

With the change

As soon as the article is published again, the article is displayed normally and there's no 404 anymore.

When you are using the page cache plugin if an article has been cached then it will still be displayed after it has been unpublished unless the cache is cleaned. In other words this PR just exposes a general issue with the page cache plugin (you need to clear the cache after any change) and just solves part of the problem - error pages when cached will still be displayed even when the state of the content has been changed to prevent the error.
In other words this is a valid issue but the PR only partially resolves it. Surely the correct thing to do is to flush the cache when the content is changed

If I remember it right, this was to address something like an upstream timeout event.

We fetch results from external site and if it's not reachable within 10 seconds it timeouts with an Joomla Error. And then that would be cached for the page Cache duration.

With the fix instead only the working request would get cached.

Correct. Instructions I gave were a simple way of testing. External sources would be harder to test, for instance a bug in an extension or in the template, causing a 500 or something.

@Chrissi2812 that usecase makes sense except I wouldnt want to ever cache that page even when it is valid and would set it up as an exception in the plugin options

This pull request has been automatically rebased to 5.3-dev.

I have tested this item ✅ successfully on afc9df6