CacheInvalidate : stop at first server not responding

[benjamin-volle]

Preconditions

All Magento versions

Steps to reproduce

1. Setup 2 Varnish servers (cache1 and cache2) in the http_cache_hosts section of "env.php"
2. Turn off the first one (cache1)
3. Try to flush the full_page by launching bin/magento cache:flush full_page

Expected result

The full_page is flushed for cache2 (the only one responding)

Actual result

The full_page is not flushed for all servers

The problem is located here :
\Magento\CacheInvalidate\Model\PurgeCache::sendPurgeRequest

In the "foreach" loop, there is a "return false" at the first exception insteag of "continue", preventing the try on all servers.

[magento-engcom-team]

Hi @synolia-bvo. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento-engcom-team give me {$VERSION} instance

where {$VERSION} is version tags (starting from 2.2.0+) or develop branches (2.2-develop +).
For more details, please, review the Magento Contributor Assistant documentation.

@synolia-bvo do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• yes
• no

[magento-engcom-team]

@engcom-backlog-nazar Thank you for verifying the issue. Based on the provided information internal tickets MAGETWO-95006, MAGETWO-95007 were created

[ghost]

Hi @synolia-bvo , thank you for your report.
We've acknowledge the issue and added to our backlog.

[magento-engcom-team]

Hi @synolia-bvo. Thank you for your report.
The issue has been fixed in #18852 by @wiardvanrij in 2.3-develop branch
Related commit(s):

• a8f662ebe2ed6a190ea34d407a6085678add93f0
• 04aa94e7062eab740d88c814277e08e0458596a1
• 0ab520a162e03e4a45161ced4bcb32eaef12ad89
• fb5a9d137e77848861b8312db39c23c9bab88f70
• 7f2c079e2ebbc604056ef359c4c627b9cd7c776d
• d74640a3c3e1c68a6e0b232178c347b219e96340
• 9a5bc5ffc8b9119b9d69cad5aa155c6b75c5d9bc
• de6af27f23374277478d1903e4e68c1f3dfdc59b
• e95de003f7cdee34977f247423d8843a115d9721

The fix will be available with the upcoming 2.3.2 release.