Error 500 During Sync

Technical Support
1

We are getting an error 500 when attempting to sync as a supervisor.

Console error message:

Denied replicating to remote server 

{id: '23376ad7-e2d2-44d6-85d2-baad7ceda3b7', error: 'forbidden', name: 'forbidden', status: 500}

Note:

  • 23376ad7-e2d2-44d6-85d2-baad7ceda3b7 is the UUID of a document of type additional_doc (created within another workflow). We are noticing this only when replicating additional_docs generated by our muting approval and death request approval workflows.

  • This is happening in a test instance, which is a clone of one of our production instances (v3.7). This test instance was upgraded to v3.13 after cloning. On prod the feature works fine as expected. We have noticed this issue across 2 different clones of prod. No issues reported from the cloning and upgrading process.

  • All the documents created before and after the additional_doc sync fine without issues. The additional_doc is not present in the medic database.

2

Hi @rmayore

Offline users aren’t allowed to replicate any types of documents, for security reasons. The docs_by_replication_key view details which documents offline users would be allowed to CRUD (create/read/update/delete) - and additionally to that, replication depth rules apply.
A document of a custom type would most definitely be blocked from being created.

This is expected.

3

To be more specific, offline users are allowed to CRUD:

  • contact docs (docs of type contact, person, clinic, health_center, district_hospital) that are descendants of their user’s facility - limited by replication_depth
  • report docs (docs of type data_record) that are about descendants of their user’s facility - limited by replication_depth
  • their own task docs (docs of type task)
  • their own target docs (docs of type target)
  • can read forms, settings, main ddoc and some other admin type docs (branding, partners, translations, z-score etc)

Any other type of doc will be blocked from being replicated, being a read, creation, edit, or deletion.

1 Like
4

@diana

This document is of type data_record , and replicates well in another instance. This is a sample of the same doc, in an instance that replicated it successfully

{
  "_id": "42f1ca18-e757-41a2-b1a9-34b5a65498ea",
  "_rev": "2-8b2b323afd9d4248c8ef6002f72d55ef",
  "patient_id": "uuid",
  "type": "data_record",
  "created_by_doc": "f2635b5b-70bc-4dbd-a237-cb7fbb2d0b18",
  "content_type": "xml",
  "form": "muting_approved",
  "parent": {
    "_id": "uuuid",
    "parent": {
      "_id": "uuuuid"
    }
  },
  "contact": {
    "_id": "uuuuuid",
    "parent": {
      "_id": "uuuuuuid"
    }
  },
  "fields": {
    "patient_id": "uuid"
  },
  "reported_date": 1660581200781,
  "geolocation_log": [
    {
      "timestamp": 1660581200784,
      "recording": {
        "code": 1,
        "message": "User denied Geolocation"
      }
    }
  ],
  "geolocation": {
    "code": 1,
    "message": "User denied Geolocation"
  },
  "tasks": [
    {
      "messages": [
        {
          "uuid": "e30640c8-7163-418c-a331-274338036428",
          "to": "reporting_unit",
          "error": "messages.errors.message.empty"
        }
      ],
      "state_history": [
        {
          "state": "pending",
          "timestamp": "2022-08-15T16:33:24.331Z"
        }
      ],
      "state": "pending"
    }
  ]
}
5

@diana

I’d post a sample of the doc that failed to replicate, if I knew of a way to extract an entire doc from the local pouch database

6

Hi @rmayore

In this case, replication failed with denied means that the offline user doesn’t have access to see the linked patient document (fields.patient_id).
Can your supervisor see this patient document? Is it replicated on their device?

7

@diana

Is there a way I can find out if the supervisor can see the patient document? Replication depth is 1 for supervisors

8

We discussed this some more on a call today and I just wanted to add the additional contact that this workflow functions properly on other instances with the same CHT version and replication depth configuration.

Some additional troubleshooting steps we are going to try:

  • Increase the replication depth and see if that resolves the issue (not an good actual resolution, but could help confirm what the problem is)
  • Verify that the behavior is the same for other users of the same workflow on the instance (and that this is not related somehow to just this one supervisor).
9

Yes, you can. While logged in as the supervisor, either:

  1. Search for the document by name or patient_id in the UI
  2. Navigate manually to the contact detail page by changing URL in the app
  3. make a curl get request to the server to see the document and use the supervisor’s credentials

If you get a not found error, then this document is not available.

With a replication_depth of 1, the supervisor only sees their facility and the direct places and people under the facility. If this patient is not a direct child of the facility, then it’s expected to not be available for the user.

To bypass replication_depth, you can use needs_signoff.

10

@diana @jkuester

Increasing replication depth to 2 increases the number of docs downloading during login exponentially (over 150k). We’ve not had a successful login yet.

This behaviour is the same for all supervisors.

11

@rmayore with that many documents, you could configure the report_depth to still be 1 while depth is still set to 2 and that would avoid having the supervisors need to sync all the data_record docs (but still allow them to access to the contacts).

That being said, I tested it locally and I believe @diana’s suggestion about setting needs_signoff to true in the muting_approved form should solve your problem (without needed to change the replication depth configuration at all…). Just having a needs_signoff field set to true in my report was enough to allow my test user to replicate a document associated with a patient_id that he did not have access to.

12

@jkuester setting depth to 2 and report_depth to 1 does somewhat reduce the number of docs to be downloaded to ~68K. This is a supervisor that downloads less that 10K docs in depth 1.

Also correct me if I’m wrong, but from this thread doesn’t need_signoff only replicate up a hierarchy? In our case we want to replicate an approval downwards in the manner Supervisor → CHW → patient

13

@jkuester @diana needs_signoff works for what we need!

2 Likes