BioPAX export to zip broken

[jvwong]

Attempt to export BioPAX via GET to /api/document/zip is returning a server error (HTTP status 500). This is happening on the production version.

I can reproduce locally when I import the production data. This error does not occur when I start with a clean database and add a new document.

[jvwong]

jvwong to test again

[jvwong]

@metincansiper I can reproduce this error locally.

I am using the rethinkdb dump of prod data. You can restore it by using restore_rethinkdb.sh

Data attached

rethinkdb_dump_20201020_000001.tar.gz

[metincansiper]

@jvwong I run the factoid from docker compose and loaded the dump of data. Then, I made some experiments by using the element jsons of the documents where biopax export fails. When I run the factoid as normal without using docker and created a document with the elements from the same json content ( omitted only the secret fields from element jsons) I see that the exports works with success.

Therefore, I do not think this problems are related to the contents of documents as most of the content comes from elements.

Did that failures always happened when you run factoid with docker (I do not know any other way of loading db dump actually)? If so I realized that in docker the grounding service does not work. It maybe related to grounding search problem in docker? I see the following logs:

webapp_container | 2020-10-23T19:56:37.417248700Z error:   Aggregate search failed
webapp_container | 2020-10-23T19:56:37.418490900Z error:    FetchError: request to http://grounding:3000/search failed, reason: connect ECONNREFUSED 198.105.244.23:3000

[jvwong]

To reproduce the errors I posted, I was running factoid and the biopax-converter without docker; rethinkdb was running in docker.

The main problem is that the production version is returning a HTTP 500.

The grounding search shouldn't matter (although I have to fix something as it complains about node/fibers being missing)

[metincansiper]

I tired that too in the past and tried again now to double check. What I am doing is that I am running the docker compose file as is and then running factoid an other port than 3000 since 3000 will be occupised. I get an error related to the rethinkdb port:

connect ECONNREFUSED 127.0.0.1:28015
    at ReqlDriverError.ReqlError [as constructor] (/Users/siperm/Documents/Workspace/factoid/node_modules/rethinkdb/errors.js:23:13)
    at new ReqlDriverError (/Users/siperm/Documents/Workspace/factoid/node_modules/rethinkdb/errors.js:68:50)
    at TcpConnection.<anonymous> (/Users/siperm/Documents/Workspace/factoid/node_modules/rethinkdb/net.js:94:27)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at TcpConnection.emit (events.js:211:7)
    at Socket.<anonymous> (/Users/siperm/Documents/Workspace/factoid/node_modules/rethinkdb/net.js:705:22)
    at emitOne (events.js:121:20)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

I believe that I must set DB_PORT environment variable to wherever the rethinkdb port is exposed to from the docker compose. However, I could not see any such setup in the docker compose related files.

[jvwong]

If you want to use docker-compose and RethinkDB you need to expose port 28015 when running factoid on loopback (localhost):

  db:
    image: pathwaycommons/rethinkdb-docker:${RETHINKDB_IMAGE_TAG:-latest}
    restart: on-failure
    container_name: db_container
    ports:
      - "${DB_ADMIN_PORT:-8080}:8080"
      - "28015:28015"
    volumes:
      - dbdata:/data

[metincansiper]

@jvwong thanks

I made a commit on unstable of factoid converters PathwayCommons/factoid-converters@6536e39. Looks like this commit fixes this issue. At least I can download zip file with that.

However, I realized one other weird thing. When there is a document where there is a reason makes the server throwing internal server the biopax related conversion/file creation etc. processes are not blocked for that but the file is created with the error content. When it comes to sbgn cases the internal server error blocks everything and the zip file would not be downloaded. I may need to find the reason behind that difference which I could not accomplish so far.

After finding that (if needed) I consider totally skipping the creation of the files for the documents where there is an internal server error. What do you think?

[jvwong]

Sounds good to skip the problematic docs, but we should ensure that we log those errors so that we know there's a problem

[maxkfranz]

After finding that (if needed) I consider totally skipping the creation of the files for the documents where there is an internal server error. What do you think?

Yes, that's a good fallback plan. Whether or not the root problem is resolved, it would be good for the conversion system to fail softly as you've suggested.

It's useful to know when a particular document fails and to log it for reference. The system shouldn't block on a single failed document, otherwise it would be difficult to see when a second document is failing in the same batch.

[metincansiper]

Okay I created #885 to resolve the issue of skipping the files where conversion fails. Besides that as I mentioned I made a commit on unstable of factoid converters PathwayCommons/factoid-converters@6536e39 that solves the actual problem of why the conversions where failing. BTW the reason of failures was that chemicals were having organism fields in the factoids while paxtools does not allow it to happen. I made a change to disable failing when such a conflict happens.

[metincansiper]

I do not know which branch of factoid converters is being actively used now on factoid. Should I merge the commit I made on unstable to the master branch of factoid-converters?

[jvwong]

Here are the two failing docs from the latest db dump:

• https://biofactoid.org/document/a6b4351d-b474-49d9-bc3d-f044513d5a0c
• https://biofactoid.org/document/13f7f251-9bf5-4b54-9360-69cfed00b6be