# Error 500 During Sync

**URL:** <https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105>\
**Category:** Technical Support\
**Created:** [August 18, 2022, 7:20am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105 "2022-08-18T07:20:49Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 18, 2022, 7:20am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/1 "2022-08-18T07:20:49Z")

</div>

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

Console error message:

```auto
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.

---

<div class="post-metadata">

**Author:** ![diana](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/diana/32/2049_2.png) [@diana](https://forum.communityhealthtoolkit.org/u/diana)\
**Post date:** [August 18, 2022, 7:48am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/2 "2022-08-18T07:48:14Z")

</div>

Hi @rmayore

Offline users aren’t allowed to replicate any types of documents, for security reasons. The [`docs_by_replication_key` view](https://github.com/medic/cht-core/blob/14e58c7e8fe51ff2874812033383500e081b6fcf/ddocs/medic/views/docs_by_replication_key/map.js) 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.

---

<div class="post-metadata">

**Author:** ![diana](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/diana/32/2049_2.png) [@diana](https://forum.communityhealthtoolkit.org/u/diana)\
**Post date:** [August 18, 2022, 7:52am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/3 "2022-08-18T07:52:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 18, 2022, 8:13am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/4 "2022-08-18T08:13:14Z")

</div>

@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

```auto
{
  "_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"
    }
  ]
}

```

---

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 18, 2022, 8:16am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/5 "2022-08-18T08:16:29Z")

</div>

@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

---

<div class="post-metadata">

**Author:** ![diana](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/diana/32/2049_2.png) [@diana](https://forum.communityhealthtoolkit.org/u/diana)\
**Post date:** [August 18, 2022, 9:03am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/6 "2022-08-18T09:03:08Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 18, 2022, 10:35am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/7 "2022-08-18T10:35:58Z")

</div>

@diana

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

---

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [August 18, 2022, 11:54am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/8 "2022-08-18T11:54:02Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![diana](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/diana/32/2049_2.png) [@diana](https://forum.communityhealthtoolkit.org/u/diana)\
**Post date:** [August 18, 2022, 3:04pm UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/9 "2022-08-18T15:04:57Z")

</div>

> [@rmayore](#):
>
> Is there a way I can find out if the supervisor can see the patient document? Replication depth is 1 for supervisors

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`.

---

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 19, 2022, 10:45am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/10 "2022-08-19T10:45:16Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [August 19, 2022, 4:43pm UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/11 "2022-08-19T16:43:03Z")

</div>

@rmayore with that many documents, you could configure the [`report_depth`](https://docs.communityhealthtoolkit.org/apps/guides/performance/replication/#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`](https://docs.communityhealthtoolkit.org/apps/guides/performance/replication/#supervisor-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.

---

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 22, 2022, 6:52am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/12 "2022-08-22T06:52:33Z")

</div>

@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](https://forum.communityhealthtoolkit.org/t/does-needs-signoff-only-work-when-there-is-an-existing-supervisor-supervisee-relationship/1551/2) 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

---

<div class="post-metadata">

**Author:** ![rmayore](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/rmayore/32/1385_2.png) [@rmayore](https://forum.communityhealthtoolkit.org/u/rmayore)\
**Post date:** [August 22, 2022, 7:31am UTC](https://forum.communityhealthtoolkit.org/t/error-500-during-sync/2105/13 "2022-08-22T07:31:43Z")

</div>

@jkuester @diana `needs_signoff` works for what we need!
