Uploaded image for project: 'Couchbase Lite'
  1. Couchbase Lite
  2. CBL-556

Reachability undermines offline reconnect logic

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.7.0
    • 2.7.0
    • iOS
    • Security Level: Public
    • None
    • 3

    Description

      When working with the troublemaker proxy I notice that the following occurs when running a continuous push replication in the face of failure:

      1. The failure happens, and in c4StatusChanged the replicator goes to offline.
      2. At the end of handleError the reachability observer is started
      3. The reachability observer immediately sends out a "network reachable" message as its initial message in the case that the network status is known
      4. This triggers a callback to reachabilityChanged and since reachable is true and the replicator is offline, this causes an immediate retry

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          The reachability works correctly but seems like to prevent immediate reconnecting loop, we could add time b/w retry for reachability.

          pasin Pasin Suriyentrakorn added a comment - The reachability works correctly but seems like to prevent immediate reconnecting loop, we could add time b/w retry for reachability.
          jimb Jim Borden added a comment -

          How about just not adding the callback until after starting the reachability observer?  It seems like the initial callback doesn't serve a good purpose since it's almost guaranteed to come in.

          jimb Jim Borden added a comment - How about just not adding the callback until after starting the reachability observer?  It seems like the initial callback doesn't serve a good purpose since it's almost guaranteed to come in.

          I haven't checked the code but I think that could be a good idea as we also have the retry logic setup for the backup.

          pasin Pasin Suriyentrakorn added a comment - I haven't checked the code but I think that could be a good idea as we also have the retry logic setup for the backup.
          Jayahari.Vavachan Jay Vavachan added a comment -

          Message Interceptor Config

          {
            "Rules": [
              {
                "RuleDirection":  "ToServer",
                "Criteria": {
                  "ApplicationFrequency": "Always",
                  "Type": "Request",
                  "Profile": "subChanges"
                },
                "OutputTransforms": [
                  {
                    "Portion": "Type",
                    "Type": "Error"
                  },
                  {
                    "Portion": "Properties",
                    "Properties": {
                      "Error-Domain": "HTTP",
                      "Error-Code" : "503"
                    },
                    "Op": "Replace"
                  },
                  {
                    "Portion": "Body",
                    "Content": "Database server is over capacity"
                  }
                ]
              }
            ]
          }
          

          Steps
          1. Run the trouble maker proxy.
          2. Run the simulator pointing to proxy.
          3. Kept the break point inside the `reachabilityChanged` method. But this didn't come inside the break point.

          Logs -> logs-reachability.txt

          I thought it is related to CBL-558. But reverting the fix, also not reproducing the issue(also seems like that is not going to cause any callback to rechabilityChanged).

          Jayahari.Vavachan Jay Vavachan added a comment - Message Interceptor Config { "Rules": [ { "RuleDirection": "ToServer", "Criteria": { "ApplicationFrequency": "Always", "Type": "Request", "Profile": "subChanges" }, "OutputTransforms": [ { "Portion": "Type", "Type": "Error" }, { "Portion": "Properties", "Properties": { "Error-Domain": "HTTP", "Error-Code" : "503" }, "Op": "Replace" }, { "Portion": "Body", "Content": "Database server is over capacity" } ] } ] } Steps 1. Run the trouble maker proxy. 2. Run the simulator pointing to proxy. 3. Kept the break point inside the `reachabilityChanged` method. But this didn't come inside the break point. Logs -> logs-reachability.txt I thought it is related to CBL-558 . But reverting the fix, also not reproducing the issue(also seems like that is not going to cause any callback to rechabilityChanged).
          Jayahari.Vavachan Jay Vavachan added a comment -

          Jim found the reason, why not able to reproduce. Since I am running SGW in same machine, now I can see the error.

          Jayahari.Vavachan Jay Vavachan added a comment - Jim found the reason, why not able to reproduce. Since I am running SGW in same machine, now I can see the error.
          Jayahari.Vavachan Jay Vavachan added a comment - fix: https://github.com/couchbase/couchbase-lite-ios/pull/2591

          Build couchbase-lite-ios-2.7.0-97 contains couchbase-lite-ios commit c75f0ac with commit message:
          CBL-556: Only retry if there is any network issues (#2591)

          build-team Couchbase Build Team added a comment - Build couchbase-lite-ios-2.7.0-97 contains couchbase-lite-ios commit c75f0ac with commit message: CBL-556 : Only retry if there is any network issues (#2591)

          People

            Jayahari.Vavachan Jay Vavachan
            jimb Jim Borden
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty