Boards never open; Wekan restarts with std::bad_alloc / V8 OOM on large datasets (works on 8.22)

[dd4y]

I am writing here as wekan community has been very uninterested to deal with this - https://github.com/wekan/wekan/issues/6132

Versions tested:

8.22: stable (boards open normally)

8.28: boards never open (infinite loading), server restarts/crashes

8.31: issue still present

Platform: Cloudron (Docker-based), Ubuntu host

Symptoms:

Web UI loads, but opening any board spins forever.

Backend restarts repeatedly; healthcheck fails (ECONNREFUSED :3000) after crash.

Logs:

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

also observed V8 OOM: FATAL ERROR: Zone Allocation failed - process out of memory

Container resources:

/sys/fs/cgroup/memory.max = 17179869184 (16GB)

/sys/fs/cgroup/memory.swap.max = max

Node heap limit (default) shows ~4144MB via require('v8').getHeapStatistics().heap_size_limit

Notes / suspicion:

Works on 8.22; regression appears after 8.23/8.24 era.

v8.23 changed publish layer (cottz:publish-relations → reywood:publish-composite).

v8.24 included Meteor 2.16 updates, async index creation, removed idmontie:migrations, etc.

v8.28 updated meteor-node-stubs.

There is an existing report of std::bad_alloc restart loop after upgrading 8.23 → 8.24 (#6098).

Happy to run additional diagnostics if you suggest flags or debug logging. I tried increasing allocated memory to 64GB or even higher, but result is the same.

[humptydumpty]

I can’t help with your troubleshooting, but xet7’s handling of the latest UI changes drove me away. If you’re not using rules and automations, give Vikunja a try.

@scooke ‘s very cool use case if you’d like to give it a read https://forum.cloudron.io/topic/5693/domain-and-vps-records-management-using-vikunja-lengthy-read