Populating the models stalls while 'Waiting for in-flight Habitat object updates'

[hheimbuerger]

I'm trying to run Neohabitat from the Docker containers (docker compose up). After resolving some initial certificate issues, I'm now stuck with trying to populate the database. The connection to the database container appears to work, but there's some synchonization issue.

I was hoping that someone more familiar with the codebase can make some guesses at potential causes, so I don't have to debug all the way down. :)

This is what it looks like when running the containers via Docker Compose:

neohabitat-neohabitat-1         | Nuking database
neohabitat-neohabitatmongo-1    | NETWORK  [listener] connection accepted from 172.18.0.4:55452 #134 (1 connection now open)
neohabitat-neohabitatmongo-1    | NETWORK  [conn134] end connection 172.18.0.4:55452 (0 connections now open)
neohabitat-neohabitat-1         | Building Regions, Avatars, Objects, and Text
neohabitat-neohabitatmongo-1    | NETWORK  [listener] connection accepted from 172.18.0.4:55460 #135 (1 connection now open)
neohabitat-neohabitatmongo-1    | NETWORK  [conn135] end connection 172.18.0.4:55460 (0 connections now open)
neohabitat-neohabitat-1         | make: *** [Makefile:71: regions] Error 1
neohabitat-neohabitat-1         | Command Fail..
neohabitat-neohabitat-1         | retry 1 ::
neohabitat-neohabitat-1         | Nuking database
[… repeated …]

(edited for readability)

And from there on, it just keeps retrying, but never succeeds. As you can see from the output of the MongoDB container, there is an incoming connection. Although the connection ends quickly, and I cannot tell whether that's the root cause of the issue, or an effect of the cause on the population side.

The Makefile is simple, it reads in line 71:

@node populateModels.js $(NEOHABITAT_MONGO_HOST) all >>.errs 2>&1

We can either read .errs at just the right moment (it is erased by the "Nuking database"), or simply call the above command manually to see what's happening internally:

root@my-neohabitat:/src/neohabitat# docker compose exec -ti neohabitat bash
[root@8bc29ed6085a neohabitat]# cd /neohabitat/db && node populateModels.js $NEOHABITAT_MONGO_HOST all
Waiting for in-flight Habitat object updates: 2461
Waiting for in-flight Habitat object updates: 2461
Waiting for in-flight Habitat object updates: 2461
Waiting for in-flight Habitat object updates: 2461
Waiting for in-flight Habitat object updates: 2461
[… repeated another ~44 times …]
Failed to update Habitat object:
TypeError: db.collection is not a function
    at eupdateArray (/neohabitat/db/populateModels.js:135:8)
    at FunctionCall.doCall_ (/neohabitat/node_modules/backoff/lib/function_call.js:156:20)
    at Backoff.emit (events.js:198:13)
    at Backoff.onBackoff_ (/neohabitat/node_modules/backoff/lib/backoff.js:53:10)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10)
[… repeated hundreds of times …]

I suspect that TypeError is a result of the timeout and not the actual root cause, right?

Does anybody have an idea where to look. I just don't know what's supposed to happen here. Does someone have a log of the success case?

[AmandaJonesAway]

There are a few places that need adjusting due to changes in mongo.
I've got a bit further than you, it seems, although I've not updated centos7 or changed the setup as much as in #389.
My mods are at master...AmandaJonesAway:neohabitat:master - I've not done a PR yet, as there are still issues after the client connects.

[hheimbuerger]

@AmandaJonesAway Yeah, stu pointed me to your changes on the Neohabitat Slack. Great work, I believe I managed to get the database populated now as well, using your changes!

[StuBlad]

As mentioned on both Discord and Slack, populateModels.js now works correctly and will populate the object database. However, writeHabitatUser.js does not work correctly. It seems to be having trouble with the hostname of the mongodb server.

[StuBlad]

This issue has been resolved.