Failed to invoke procedure apoc.export.cypher.all:

[ayushKataria]

Getting below error when trying to run apoc.export.cypher.all:

Caused by: org.neo4j.internal.kernel.api.exceptions.EntityNotFoundException: Unable to load NODE with id 783244.

The node id changes every time we run it. If we restart neo4j and rerun this, it works fine but if after a few days start getting this error again.

Neo4j version: 4.2.8
apoc version: 4.0.1

[vga91]

@ayushKataria

I've never seen this error, but first of all I would try to change version of apoc.
In fact your version of neo4j and that of apoc are not compatible (although often almost everything works).
You should install a 4.2.x.x apoc (the latest is 4.2.0.10).

See here https://neo4j.com/labs/apoc/4.4/installation/#neo4j-server

[ayushKataria]

Sorry, a type from me. It is actually 4.2.0.1 version of apoc. Will upgrade to the 4.2.0.10 anyways and try.

Also, I had seen a community post with the same issue here. We also starting seeing this issue after we upgraded from 3.5 to 4.2 neo4j version.

[ayushKataria]

Even after changing to 4.2.0.10, we are still seeing the same issue. Any idea what may have caused it?

[vga91]

@ayushKataria
I just tried some migration from 3.5 to 4.x, but everything works. Maybe it could depend on the dataset.

Can you try to execute a consistency check with your database?

Also, when the error Unable to load NODE with id NNNN is thrown,
are you able to execute a match (n) where id(n) = NNNN return n?

[ayushKataria]

@vga91 match (n) where id(n) = NNNN return n runs fine but obviously doesn't return any node. But any new node I create has a nodeId +1 of the unavailable one, most of the time. Not sure, if that means anything though.

I'll try the consistency check and share.

[ayushKataria]

@vga91 I ran the consistency check, it didn't produce a inconsistencies file but this was the console output from it.

WARNING: Max 1024 open files allowed, minimum of 40000 recommended. See the Neo4j manual.
neo4j 4.2.8
VM Name: OpenJDK 64-Bit Server VM
VM Vendor: Amazon.com Inc.
VM Version: 11.0.12+7-LTS
JIT compiler: HotSpot 64-Bit Tiered Compilers
VM Arguments: [-XX:+UseParallelGC, -Xmx23800m, -Dfile.encoding=UTF-8]
2022-06-29 15:34:09.807+0000 INFO  [o.n.k.i.s.f.RecordFormatSelector] Selected RecordFormat:PageAlignedV4_1[AF4.1.a] record format from store /mydata_ebs_1/neo4j-4.2-data/data/databases/neo4j
2022-06-29 15:34:09.808+0000 INFO  [o.n.k.i.s.f.RecordFormatSelector] Format not configured for store /mydata_ebs_1/neo4j-4.2-data/data/databases/neo4j. Selected format from the store files: RecordFormat:PageAlignedV4_1[AF4.1.a]
Index structure consistency check
....................  10%
....................  20%
....................  30%
....................  40%
....................  50%
....................  60%
....................  70%
....................  80%
....................  90%
.................... 100%
NodeBasedMemoryLimiter:
  pageCacheMemory:26.89GiB
  jvmMemory:20.66GiB
  machineMemory:62.03GiB
  perNodeMemory:11B
  nodeHighId:21479518
  occupiedMemory:47.56GiB
  ==> numberOfRanges:1
  ==> numberOfNodesPerRange:21479518
STARTED Initialize index sizes
COMPLETED Initialize index sizes, took 24ms
These are considered small node indexes (3):
  org.neo4j.internal.schema.IndexDescriptor@1
  org.neo4j.internal.schema.IndexDescriptor@2
  org.neo4j.internal.schema.IndexDescriptor@3
Consistency check

STARTED IndexChecker[entityType:NODE,indexesToCheck:0]

COMPLETED IndexChecker[entityType:NODE,indexesToCheck:0], took 501ms

STARTED NodeChecker[highId:21479518,indexesToCheck:3]
....................  10%
....................  20%
....................  30%
.
COMPLETED NodeChecker[highId:21479518,indexesToCheck:3], took 22s 219ms

STARTED RelationshipGroupChecker[highId:12736]

COMPLETED RelationshipGroupChecker[highId:12736], took 24ms

STARTED RelationshipChecker[highId:8965861,indexesToCheck:0]
...................  40%
.......
COMPLETED RelationshipChecker[highId:8965861,indexesToCheck:0], took 816ms

STARTED RelationshipChainChecker[highId:8965861]
.............  50%
............
RelationshipChainChecker[highId:8965861] FORWARD took 1s 800ms

RelationshipChainChecker moving over to backwards relationship chain checking
........  60%
..................
RelationshipChainChecker[highId:8965861] BACKWARD took 1s 760ms

COMPLETED RelationshipChainChecker[highId:8965861], took 3s 564ms
..  70%
....................  80%
....................  90%
.................... 100%

[vga91]

@ayushKataria Yes, everything looks good with the consistency-check.

Just to exclude some causes, does the problem occur with the apoc.export.json.all and the apoc.export.csv.all too?

Anyway, I have found an issue that looks similar. Along the lines of this, by copying the database following this guide, are you able to solve the problem?

If that doesn't work, could you share a dump of the database, or a part of it, with which i could replicate the bug?

[conker84]

@ayushKataria ping

[ayushKataria]

@vga91 It only occurred with apoc.export.cypher.all and not with apoc.export.json.all or apoc.export.csv.all.

Eventually, we ended up replicating the database in a fresh install of neo4j and haven't seen the issue since. We replicated using a successful run of apoc.export.cypher.all and running these cypher queries in the new install.

One more weird thing we saw was, that the database folder size was 151GB in the previous install, while in the new install it was only 2.5GB. Any idea why this might be happening?