# Is purging broken because of #7280

**URL:** <https://forum.communityhealthtoolkit.org/t/is-purging-broken-because-of-7280/1816>\
**Category:** Technical Support\
**Created:** [April 1, 2022, 5:46pm UTC](https://forum.communityhealthtoolkit.org/t/is-purging-broken-because-of-7280/1816 "2022-04-01T17:46:52Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![kenn](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/kenn/32/55_2.png) [@kenn](https://forum.communityhealthtoolkit.org/u/kenn)\
**Post date:** [April 1, 2022, 5:46pm UTC](https://forum.communityhealthtoolkit.org/t/is-purging-broken-because-of-7280/1816/1 "2022-04-01T17:46:52Z")

</div>

Purging hasn’t run on a large project instance since Dec, 2021. I’d like to confirm that the problem is [Server Side Purge does not complete to the end · Issue #7280 · medic/cht-core · GitHub](https://github.com/medic/cht-core/issues/7280) fixed in 3.14.0. What’s the best way to confirm this?

I can see purging log events `2022-04-01 17:35:50 INFO: Task purging completed` for today.

---

<div class="post-metadata">

**Author:** ![mrjones](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/mrjones/32/681_2.png) [@mrjones](https://forum.communityhealthtoolkit.org/u/mrjones)\
**Post date:** [April 1, 2022, 10:00pm UTC](https://forum.communityhealthtoolkit.org/t/is-purging-broken-because-of-7280/1816/2 "2022-04-01T22:00:26Z")

</div>

Hey @kenn !

Are you debugging an instance that has been upgrade to \>3.14.0 with the fix or a version \<3.14.0 without the fix? I ask because you said both “Purging hasn’t run … since Dec, 2021” and then had a log file showing purging run today (`2022-04-01`).

If I had to guess, maybe you’re on \>3.14.0 and you’re seeing poor performance of some users who have above 20k docs maybe? I suspect this because the original bug only the initiation messages, and not the completion message (which you’re seeing), would be logged, like so:

```auto
[2021-08-27 08:30:00] 2021-08-27 08:30:00 INFO: Running server side purge 
[2021-08-27 09:30:00] 2021-08-27 09:30:00 INFO: Running server side purge 
[2021-08-27 14:00:00] 2021-08-27 14:00:00 INFO: Running server side purge 

```

The [3.14.0 purge consideration docs](https://docs.communityhealthtoolkit.org/apps/guides/performance/purging/#considerations) call out the 20k threshold as being treated differently:

> As of 3.14.0, contacts that have more than 20,000 associated reports + messages will be skipped, and none of their associated reports and messages will be purged. A single contact that has more than 20,000 associated records most likely points to a configuration issue. Skipped contacts’ ids are reported both in logs and in `purgelog` files

Can you check your logs to see if you have any relevant entries? Or, if I guessed wrong the specifics of your situation, please fill me in so we can get you sorted!

---

<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:** [April 2, 2022, 5:25am UTC](https://forum.communityhealthtoolkit.org/t/is-purging-broken-because-of-7280/1816/3 "2022-04-02T05:25:19Z")

</div>

Hi @kenn

Inspecting the instance, the `medic-sentinel` process is up, and active, with uptime since Jan 26.  
This is not the same behavior we saw with the original instance that reported this (where the sentinel process ran out of memory).  
However, I’ve inspected the logs after the last unsuccessful purging (6h ago) and I can see a couchdb request failing (when parsing the response) and then purging failing as a consequence (failing was graceful).

Running the same request locally, I see the result contains 423.644 reports.  
Trying to run the same request with `include_docs`, I get:

```auto
node:buffer:806
    return this.utf8Slice(start, end);
                ^

Error: Cannot create a string longer than 0x1fffffe8 characters
    at Buffer.toString (node:buffer:806:17)
    at Request.<anonymous> (/home/diana/projects/medic-utils/node_modules/request/request.js:1135:39)
    at Request.emit (node:events:527:28)
    at IncomingMessage.<anonymous> (/home/diana/projects/medic-utils/node_modules/request/request.js:1083:12)
    at Object.onceWrapper (node:events:641:28)
    at IncomingMessage.emit (node:events:539:35)
    at endReadableNT (node:internal/streams/readable:1342:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  code: 'ERR_STRING_TOO_LONG'
}

```

This confirms it’s the same issue, where a batch of contacts has too many reports to be processed at one time.