fix: fail fast if remote is not reachable#41210
Conversation
bb7b5b8 to
7d32e4c
Compare
7d32e4c to
6a853e0
Compare
phil-davis
left a comment
There was a problem hiding this comment.
and code-style needs to be fixed
9f7fae9 to
ac07d8c
Compare
952c78f to
80304f2
Compare
|
Various acceptance tests for federated sharing are failing with: Example: https://drone.owncloud.com/owncloud/core/39820/96/19 Maybe the test environment is not so good, or maybe the new code is too enthusiastic about deciding that the remote is not reachable. I will have a look... |
|
@phil-davis any idea yet what is going on here? THX a lot |
80304f2 to
5ecb099
Compare
| $resp = $externalManager->testRemoteUrl(\OC::$server->getHTTPClientService(), $remote); | ||
| if ($resp === false) { | ||
| \OCP\JSON::error(['data' => ['message' => $l->t('Remote is unreachable')]]); | ||
| exit(); | ||
| } | ||
|
|
There was a problem hiding this comment.
The failing tests are all scenarios where a user tries to add a public link share.
The "federated" share is actually a public link.
That comes through this code.
Variable $remote at this point has the scheme http:// on the front.
But testRemoteUrl expects a URL without the scheme on the front.
I hacked the code like this:
$x = preg_replace("(^https?://)", "", $remote);
$resp = $externalManager->testRemoteUrl(\OC::$server->getHTTPClientService(), $x);
if ($resp === false) {
\OCP\JSON::error(['data' => ['message' => $l->t("Remote '$x' is unreachable")]]);
exit();
}
Now I run a test scenario:
make test-acceptance-api BEHAT_FEATURE=tests/acceptance/features/apiFederationToRoot1/savePublicShare.feature:22
...
Feature: Save public shares created by oC users
Background: # /home/phil/git/owncloud/core/tests/acceptance/features/apiFederationToRoot1/savePublicShare.feature:4
Given using server "LOCAL" # FeatureContext::usingServer()
And user "Alice" has been created with default attributes and without skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
Scenario: Mount public share and then delete (local server share) # /home/phil/git/owncloud/core/tests/acceptance/features/apiFederationToRoot1/savePublicShare.feature:22
Given user "Brian" has been created with default attributes and without skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
And user "Alice" has created folder "/PARENT" # FeatureContext::userHasCreatedFolder()
And user "Alice" has created a public link share with settings # FeatureContext::userHasCreatedAPublicLinkShareWithSettings()
| path | /PARENT |
| permissions | read |
And user "Brian" has added the public share created from server "LOCAL" using the sharing API # FeatureContext::userHasAddedPublicShareCreatedByUser()
Sharing::userHasAddedPublicShareCreatedByUser
Failed to save public share.
'Remote '172.17.0.1:8080' is unreachable'
Failed asserting that 'error' is not equal to 'error'.
But it still complains that '172.17.0.1:8080` is not reachable - that is my test installation which is running fine.
I wonder what is the next piece of this puzzle?
|
The failing test scenarios are the ones about Brian adding a public share. The usual case of users adding a federated share that is an ordinary file share on another server, that works. |
|
If one of the calls in If I separate out each I can just have it do one And that still gets But I can manually do: So the So I suppose that there is some problem with how |
|
@phil-davis THX a lot for the analysis! Much appreciated! |
8a95a20 to
5410eab
Compare
SSL issue |
f14cf07 to
07bab99
Compare
28360d9 to
7095340
Compare
7095340 to
4fe718e
Compare
|
@phil-davis mind another review? THX |
phil-davis
left a comment
There was a problem hiding this comment.
If the remote system is not listening on port 80, but some other port, then the checks do not work - they get directed to the "default" port 80, but need to be directed to the correct port.
See the last commit of PR #41237 - with that extra code the tests pass for me in my dev setup that has 2 servers running on localhost port 8080 and 8180 on my laptop.
| if ($this->testUrl($clientService, $schema . $remote . '/status.php', false, true)) { | ||
| \OC::$server->getLogger()->error("Remote $schema$remote/status.php reachable"); | ||
| return true; | ||
| } |
There was a problem hiding this comment.
| if ($this->testUrl($clientService, $schema . $remote . '/status.php', false, true)) { | |
| \OC::$server->getLogger()->error("Remote $schema$remote/status.php reachable"); | |
| return true; | |
| } | |
| if ($this->testUrl($clientService, $schema . $remote . '/status.php', false, true)) { | |
| return true; | |
| } | |
| \OC::$server->getLogger()->error("Remote $schema$remote/status.php not reachable"); |
If the host:port of the remote is completely down, then testUrl is returning false, but I get nothing in the log about it.
Maybe move the error logging to the unhappy path, and don't log when reachable.
There was a problem hiding this comment.
thx for catching this 🙏
|
Note: for my local testing, I found that this scenario was good to run: That scenario uses both local and remote (federated) servers and a public link. |
|



Description
Not responding remote servers can cause bad user experience.
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: