Connection error bug when sending report via RapidPro

[Adnan_Alhassan]

I am trying to generate a report on CHT via RapidPro. I keep getting connection_error. Has anyone here ever encountered this before?

Below is the request and response from RapidPro:

request

URL https://<username>:<password>@itech-zimbabwe.dev.medicmobile.org/api/v2/records Elapsed 15,002ms 
30-05-2022 12:00
0

POST /api/v2/records HTTP/1.1
Host: itech-zimbabwe.dev.medicmobile.org
User-Agent: RapidProMailroom/5.6.2
Content-Length: 531
Accept: application/json
Content-Type: application/json
X-Mailroom-Mode: normal
Accept-Encoding: gzip

{"_id":"4b84148b-7f94-485a-9d96-b2c96845761a","_meta":{"form":"visit_date_change_request"},"_rev":"2-3b01080087cbb53ef8da425ef8f9c811","content_type":"XML","form":"visit_date_change_request","is_task":true,"parent":"e86ab78a-4c1c-44b5-ada1-465507665f71","patient_id":"fe78fdc7-e8a7-42ce-9f22-c6cccb0094fb","patient_name":"rrr bbbb","patient_phone":"telegram:1718348434","payload":{"days_since_last_visit":"7","flow_id":"7adc93c2-cdef-4af2-9078-1d444c1977a8","will_return":"false"},"reported_date":"2022-05-30","type":"data_record"}
connection error

app_settings form:

"forms": {
"VISIT_DATE_CHANGE_REQUEST": {
      "meta": {
        "code": "visit_date_change_request",
        "translation_key": "Visit Date Change Request",
        "form": "visit_date_change_request"
      },
      "fields": {
        "patient_id": {
          "labels": {
            "short": {
              "translation_key": "Patient ID"
            },
            "tiny": "form.visit_date_change_request.patient_id.tiny"
          },
          "position": 0,
          "type": "string",
          "required": true
        },
        "reported_date": {
          "labels": {
            "short": {
              "translation_key": "Reported Date"
            },
            "tiny": "form.visit_date_change_request.reported_date.tiny"
          },
          "type": "date",
          "required": true,
          "position": 4
        },
        "patient_name": {
          "labels": {
            "short": {
              "translation_key": "Patient Name"
            },
            "tiny": "form.visit_date_change_request.patient_name.tiny"
          },
          "type": "string",
          "position": 5,
          "required": true
        },
        "is_task": {
          "labels": {
            "short": {
              "translation_key": "Is Task"
            }
          },
          "type": "boolean",
          "position": 6
        },
        "patient_phone": {
          "labels": {
            "short": {
              "translation_key": "Patient Phone Number"
            }
          },
          "type": "string",
          "position": 7
        }
      },
      "facility_reference": "parent"
    }
  }

[kitsao]

Hello @Adnan_Alhassan, the configuration looks good. A curl request using the payload works fine. You may want to get rid of

"content_type":"XML"

since VISIT_DATE_CHANGE_REQUEST is a JSON form. Otherwise, you might end up with errors in the resulting report.

The connection error you’re getting may result from a disallowed network or an unsuccessful response from the API end point. I think the latter is an area of focus.

If you receive notifications in case of such errors:

• How frequent do they occur?
• Are there patterns such as specific times of the day when you experience the errors?
• Are there triggers?
• What about API logs to inform the health of the API?

Share as much details as possible. cc @henok @hareet

[Adnan_Alhassan]

We could not reproduce the error until now.
The connection error issue returned after deployment on the 4th of August.
Attached below is a log of the deployment timestamp.

[Adnan_Alhassan]

From the logs on RapidPro, we can confirm the error returned after the deployment and seems to be a timeout error.

Attached below is a log of the webhook events from RapidPro.

[Adnan_Alhassan]

[jkuester]

@Adnan_Alhassan can we get the logs from the api server during the time when one or more of these errors has occurred? It appears that some (most?) of the requests make it through, but some fail. We can check to see if api is logging any kind of error at the time.

[Adnan_Alhassan]

@jkuester, can you spare some time to review the issue together this week? Thanks.

[jkuester]

Sure! Feel free to drop a meeting on my calendar whenever I am free. (I will miss the standup on Thus, though, since I have a conflict…)