fix for probe loop in case that network of contact has changed
This fixes a loop of probes / contact updates where the network has been apup and for whatever reason is now feed. In this case the contact hasn't been updated and rescheduled with next_update as null resulting in a huge number of queries. The call to hasLocalData has been moved a bit up as it checks for values that otherwise would be emptied befare the call. Fixes #13037
This commit is contained in:
parent
d272cecd55
commit
084cd955a2
1 changed files with 3 additions and 3 deletions
|
@ -2682,6 +2682,8 @@ class Contact
|
|||
return true;
|
||||
}
|
||||
|
||||
$has_local_data = self::hasLocalData($id, $contact);
|
||||
|
||||
$uid = $contact['uid'];
|
||||
unset($contact['uid']);
|
||||
|
||||
|
@ -2702,9 +2704,7 @@ class Contact
|
|||
|
||||
$updated = DateTimeFormat::utcNow();
|
||||
|
||||
$has_local_data = self::hasLocalData($id, $contact);
|
||||
|
||||
if (!Probe::isProbable($ret['network'])) {
|
||||
if (!Probe::isProbable($ret['network']) && !Probe::isProbable($contact['network'])) {
|
||||
// Periodical checks are only done on federated contacts
|
||||
$failed_next_update = null;
|
||||
$success_next_update = null;
|
||||
|
|
Loading…
Reference in a new issue