Replication won't work after a fresh install

[welcoMattic]

I have a self hosted couch DB, the connection is ok (checked in the plugin config panel)

But when I start a replication:

10/24/2022, 5:57:35 PM->Replication error
10/24/2022, 5:57:35 PM->error:{timeout,{gen_server,call,
                     [couch_proc_manager,
                      {get_proc,{doc,<<"_design/replicate">>,
                                     {1,
                                      [<<27,131,204,91,235,88,49,143,18,174,
                                         219,90,192,15,224,154>>]},
                                     {[{<<"ver">>,2},
                                       {<<"filters">>,
                                        {[{<<"default">>,
                                           <<"function(doc, req) {\n        return !(\"remote\" in doc && doc.remote);\n      }">>},
                                          {<<"push">>,
                                           <<"function(doc, req) {\n        return true;\n      }">>},
                                          {<<"pull">>,
                                           <<"function(doc, req) {\n        return !(doc.type && doc.type == \"leaf\");\n      }">>}]}}]},
                                     [],false,[]},
                                {<<"_design/replicate">>,
                                 <<"1-1b83cc5beb58318f12aedb5ac00fe09a">>}},
                      5000]}}
10/24/2022, 5:57:35 PM->Replication stopped.
10/24/2022, 5:57:35 PM->Retry with lower batch size:8/5
10/24/2022, 5:57:35 PM->Oneshot Sync begin... (sync)

What is the problem? I used the "Periodic w/ batch" preset. My vault is not big (10 little files).

(I run Obsidian from ArchLinux)

[vrtmrz]

Thank you for your notification! It looks like a problem with CouchDB. I had seen this in several previous versions, but it should be fixed in the current CouchDB. But, (from my note) the workaround is to set a bigger value to _config/couch_httpd_auth/timeout (here in Fauxton).

Could you please try this workaround? And for our knowledge, may I ask information on CouchDB, which you are using?

[welcoMattic]

I'm using 3.2.2 of CouchDB. I increased the couch_httpd_auth/timeout value, but it changes nothing.

It seems to be related to the filters, if I remove the filter from the query : https://localhost/my_database/_changes?style=all_docs&filter=replicate/pull&since=0&limit=35 I get some results, no error. If I leave the filter, I get an error.

[vrtmrz]

Thank you for the detail and testing! It possibly is caused by a filter. We have to use the filter to reading chunks online. Or we can fully synchronise all chunks while replication by disabling Read chunks online in the Sync Settings pane. If it has been disabled, the filter will not be used. (But it is not the real solution)

The Query servers may not be working properly. Is anything shown in the log of the server?

[welcoMattic]

It works while disabling Read chunks online :+1: thanks. I'll keep this setting off until there is a fix for the filter.

[welcoMattic]

The logs on the server are the same as what I post in the original issue comment :arrow_up:

[vrtmrz]

I'm relieved for the moment. But Read chunks online will improve the performance, so I will investigate it a little more.

[henrywintif]

Still having an issue with conflicts in _design/replicate file

--

After delving deeper, I'm finding that we fetch the server for _design/replicate? and get a 404, so the code creates its own version and tries to PUT and that's what fails because its putting as though there's no version on the remote DB because it queried incorrectly the first time.

I can try to make a PR, although I don't really know how to run local plugins, so we'll see how that goes

--

I'm seeing on line 11341 of the compiled code, a line const url = genDBUrl(host, id + paramsToStr(params));. The params is an empty object, so my first thought was to replace the line with const url = genDBUrl(host, id + Object.isEmpty(params) ? '' : paramsToStr(params)); but it looks like this is actually not in this repository and is actually from an imported package. Not sure I'll be able to do much more work here, but I'll update if anything works out better. I'm not sure whether or not the adapter is playing a role.

[henrywintif]

Currently I might have fixed the issue in my nginx reverse proxy config. DB is in a subdirectory, /couchdb. See settings below:

if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin" always;
  add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Access-Control-Allow-Methods' 'GET, PUT, OPTIONS,DELETE';
        add_header 'Content-Length' 0;
        add_header 'Content-Type' 'text/plain charset=UTF-8';

add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, Authorization';

        return 204;
    }

## Redirects files with question marks at the end
if ($request_uri ~ ^(.*)\?$) { 
  add_header 'Access-Control-Allow-Origin' "$http_origin" always;
  add_header 'Access-Control-Allow-Credentials' 'true' always;
  return 301 $1; 
}

    rewrite ^ $request_uri;
    rewrite ^/couchdb/(.*) /$1 break;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

[henrywintif]

Still having errors with endpoint _changes?style=all_docs&since=0&limit=50

[vrtmrz]

Sorry for being late! I missed this! CouchDB is usually responding to CORS preflight requests automatically, and we should not be required to configure them in nginx. (Origins in responses are automatically chosen from origins in local.ini)

However, I checked my database and noticed that my design-document also had been conflicted. I did not realise that so, may the content of the conflict be an issue. Could you please try resolving the conflict via Fauxton? It can be resolved on http://example.com/your_couchdb_path/_utils/#database/your_databasename/_design/replicate.