[GH-ISSUE #42] TypeError: Unknown chunk type 91 while reading record at

gitea-mirror commented

2026-05-23 08:27:13 -06:00

Owner

Originally created by @jkapenieks on GitHub (Sep 5, 2021).
Original GitHub issue: https://github.com/appy-one/acebase/issues/42

Originally assigned to: @appy-one on GitHub.

Hi Acebase team, thanks for your great product.

I've run into a problem during my tests of Acebase server (acebase-server@1.4.0 running on Nodejs).
I've created a new database and have a script running that stores data in database.

After a while my server kept crashing and I noticed this kind of error (see below).
I'm not able to run any queries or delete data. This causes crash of my server script and this error appears in the server log.
NodeReader.getValue:child error: TypeError: Unknown chunk type 91 while reading record at "/items/0/3/16766808/item_data" @197,405
at NodeReader.readHeader (/......./node_modules/acebase/src/storage-acebase.js:2575:23)
at async NodeReader.getValue (/......./node_modules/acebase/src/storage-acebase.js:1843:13)
at async loadChildValue (/......./node_modules/acebase/src/storage-acebase.js:1919:37)
at async Promise.all (index 2)
at async NodeReader.getValue (/......./node_modules/acebase/src/storage-acebase.js:1963:21)
at async loadChildValue (/......./node_modules/acebase/src/storage-acebase.js:1919:37)

This is what I tried:
server.db.query('items')
.remove(() => {
// Old junk gone
});

Then I was trying to delete the node directly:

server.db.ref('items/0/3/16766808/item_data')
.remove()
.then(() => {

});

This was the error:
/......./node_modules/acebase/src/storage-acebase.js:2575
throw new TypeError(Unknown chunk type ${type} while reading record at ${this.address});
^

TypeError: Unknown chunk type 91 while reading record at "/items/0/3/16766808/item_data" @197,405
at NodeReader.readHeader (/......./node_modules/acebase/src/storage-acebase.js:2575:23)
at async NodeReader.getAllocation (/......./node_modules/acebase/src/storage-acebase.js:1773:9)
at async /......./node_modules/acebase/src/storage-acebase.js:2688:36
at async Promise.all (index 0)
at async _mergeNode (/......./node_modules/acebase/src/storage-acebase.js:2701:5)
at async Object.write [as _customWriteFunction] (/......./node_modules/acebase/src/storage-acebase.js:1420:28)
at async AceBaseStorage._updateNode (/......./node_modules/acebase/src/storage-acebase.js:1433:26)
at async AceBaseStorage.setNode (/......./node_modules/acebase/src/storage-acebase.js:1349:9)
at async DataReference.set (/......./node_modules/acebase-core/dist/data-reference.js:158:13)
error: Forever detected script exited with code: 1

Originally created by @jkapenieks on GitHub (Sep 5, 2021). Original GitHub issue: https://github.com/appy-one/acebase/issues/42 Originally assigned to: @appy-one on GitHub. Hi Acebase team, thanks for your great product. I've run into a problem during my tests of Acebase server (acebase-server@1.4.0 running on Nodejs). I've created a new database and have a script running that stores data in database. After a while my server kept crashing and I noticed this kind of error (see below). I'm not able to run any queries or delete data. This causes crash of my server script and this error appears in the server log. NodeReader.getValue:child error: TypeError: Unknown chunk type 91 while reading record at "/items/0/3/16766808/item_data" @197,405 at NodeReader.readHeader (/......./node_modules/acebase/src/storage-acebase.js:2575:23) at async NodeReader.getValue (/......./node_modules/acebase/src/storage-acebase.js:1843:13) at async loadChildValue (/......./node_modules/acebase/src/storage-acebase.js:1919:37) at async Promise.all (index 2) at async NodeReader.getValue (/......./node_modules/acebase/src/storage-acebase.js:1963:21) at async loadChildValue (/......./node_modules/acebase/src/storage-acebase.js:1919:37) This is what I tried: server.db.query('items') .remove(() => { // Old junk gone }); Then I was trying to delete the node directly: server.db.ref('items/0/3/16766808/item_data') .remove() .then(() => { }); This was the error: /......./node_modules/acebase/src/storage-acebase.js:2575 throw new TypeError(`Unknown chunk type ${type} while reading record at ${this.address}`); ^ TypeError: Unknown chunk type 91 while reading record at "/items/0/3/16766808/item_data" @197,405 at NodeReader.readHeader (/......./node_modules/acebase/src/storage-acebase.js:2575:23) at async NodeReader.getAllocation (/......./node_modules/acebase/src/storage-acebase.js:1773:9) at async /......./node_modules/acebase/src/storage-acebase.js:2688:36 at async Promise.all (index 0) at async _mergeNode (/......./node_modules/acebase/src/storage-acebase.js:2701:5) at async Object.write [as _customWriteFunction] (/......./node_modules/acebase/src/storage-acebase.js:1420:28) at async AceBaseStorage._updateNode (/......./node_modules/acebase/src/storage-acebase.js:1433:26) at async AceBaseStorage.setNode (/......./node_modules/acebase/src/storage-acebase.js:1349:9) at async DataReference.set (/......./node_modules/acebase-core/dist/data-reference.js:158:13) error: Forever detected script exited with code: 1

gitea-mirror closed this issue

2026-05-23 08:27:15 -06:00

gitea-mirror commented

2026-05-23 08:27:17 -06:00

Author

Owner

@jkapenieks commented on GitHub (Sep 5, 2021):

Also, I noticed that my Acebase server script crashed when I was trying to navigate to the node: items/0/3/16766808/item_data on Acebase Web Manager.

@jkapenieks commented on GitHub (Sep 5, 2021): Also, I noticed that my Acebase server script crashed when I was trying to navigate to the node: items/0/3/16766808/item_data on Acebase Web Manager.

gitea-mirror commented

2026-05-23 08:27:18 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 6, 2021):

Thanks for reporting this. The best and quickest way for me to investigate this issue is having access to the actual data. If you can send me a copy of the data.db file through wetransfer.com, I will be able to poke into the binary data and see what's wrong and what might have caused it. You can send it to me@appy.one

Note that if your data contains personal and/or sensitive data, please create a copy of the db and anonymize your data as much as possible before sending. I will treat your data confidentially and will remove all copies from my system when done!

@appy-one commented on GitHub (Sep 6, 2021): Thanks for reporting this. The best and quickest way for me to investigate this issue is having access to the actual data. If you can send me a copy of the data.db file through [wetransfer.com](wetransfer.com), I will be able to poke into the binary data and see what's wrong and what might have caused it. You can send it to me@appy.one Note that if your data contains personal and/or sensitive data, please create a copy of the db and anonymize your data as much as possible before sending. I will treat your data confidentially and will remove all copies from my system when done!

gitea-mirror commented

2026-05-23 08:27:19 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 15, 2021):

Can you please reply

@appy-one commented on GitHub (Sep 15, 2021): Can you please reply

gitea-mirror commented

2026-05-23 08:27:20 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 16, 2021):

I'm closing this issue. If you would like this fixed @jkapenieks, please reply. For anyone else running into this issue, please also let me know.

@appy-one commented on GitHub (Sep 16, 2021): I'm closing this issue. If you would like this fixed @jkapenieks, please reply. For anyone else running into this issue, please also let me know.

gitea-mirror commented

2026-05-23 08:27:21 -06:00

Author

Owner

@neilsutcliffe commented on GitHub (Aug 21, 2022):

Hi. I've ran into this as well. One of my paths refuses to read, which means I can't update or remove it.

Is there anyway to nuke it from orbit without reading it, or to read it and ignore errors

I can send you the database file, but at the moment, I'm just trying to recover my data from the last time I backed up.

@neilsutcliffe commented on GitHub (Aug 21, 2022): Hi. I've ran into this as well. One of my paths refuses to read, which means I can't update or remove it. Is there anyway to nuke it from orbit without reading it, or to read it and ignore errors I can send you the database file, but at the moment, I'm just trying to recover my data from the last time I backed up.

gitea-mirror commented

2026-05-23 08:27:21 -06:00

Author

Owner

@neilsutcliffe commented on GitHub (Aug 21, 2022):

Tried... await acebaseLocal.ref('/image/7ddb9f615c2d9947be799b99d17ed59b11c61959[1]').set({})

GetTypeError: Unknown chunk type 112 while reading record at "/image/7ddb9f615c2d9947be799b99d17ed59b11c61959[1]" @51,340

I've also tried set([]) to the key directly, and also remove

@neilsutcliffe commented on GitHub (Aug 21, 2022): Tried... `await acebaseLocal.ref('/image/7ddb9f615c2d9947be799b99d17ed59b11c61959[1]').set({})` Get`TypeError: Unknown chunk type 112 while reading record at "/image/7ddb9f615c2d9947be799b99d17ed59b11c61959[1]" @51,340` I've also tried `set([])` to the key directly, and also `remove`

gitea-mirror commented

2026-05-23 08:27:23 -06:00

Author

Owner

@appy-one commented on GitHub (Aug 22, 2022):

@neilsutcliffe Thanks for reporting this.

Are you running AceBase in a multi-process/threaded setup?

Also, I see you are directly updating an array entry, which is discouraged because of reasons described here: Using arrays. In most situations, it's better to use object collections.

I'll add a function to overwrite records today, so you will be able to fix this broken record.

@appy-one commented on GitHub (Aug 22, 2022): @neilsutcliffe Thanks for reporting this. Are you running AceBase in a multi-process/threaded setup? Also, I see you are directly updating an array entry, which is discouraged because of reasons described here: [Using arrays](https://github.com/appy-one/acebase#using-arrays). In most situations, it's better to use object collections. I'll add a function to overwrite records today, so you will be able to fix this broken record.

gitea-mirror commented

2026-05-23 08:27:24 -06:00

Author

Owner

@neilsutcliffe commented on GitHub (Aug 22, 2022):

I'm running a next app with the built in api. So single threaded AFAIK.

In terms of how I was using arrays, I was setting the whole array at once, overwriting when updating.

path is like /image/7ddb9f615c2d9947be799b99d17ed59b11c61959

await acebaseFix.ref(path).set(images) // Update via overwrite
await acebaseFix.ref(path).set(newImages) // Create from scratch
await acebaseFix.ref(path).remove() // Delete

Oh, the image array members are structured...

export interface Image {
  width: number;
  height: number;
  img: string;
  original: string;
  url: string;
  cat?: string;
}

I'll give object collections a try, but I think the use case is fine, as I wasn't mutating or changing the array.

Thanks for getting back quickly!

@neilsutcliffe commented on GitHub (Aug 22, 2022): I'm running a next app with the built in api. So single threaded AFAIK. In terms of how I was using arrays, I was setting the whole array at once, overwriting when updating. path is like `/image/7ddb9f615c2d9947be799b99d17ed59b11c61959` `await acebaseFix.ref(path).set(images)` // Update via overwrite `await acebaseFix.ref(path).set(newImages)` // Create from scratch `await acebaseFix.ref(path).remove()` // Delete Oh, the image array members are structured... ``` export interface Image { width: number; height: number; img: string; original: string; url: string; cat?: string; } ``` I'll give object collections a try, but I think the use case is fine, as I wasn't mutating or changing the array. Thanks for getting back quickly!

gitea-mirror commented

2026-05-23 08:27:24 -06:00

Author

Owner

@appy-one commented on GitHub (Aug 23, 2022):

I've published version 1.22.2,which now supports node recovery. See #142 for more info
Let me know if that works.
Also, if you are sure you are not auto-scaling your app in the cloud, let me know if you find a reproducible way to "break" a node!

@appy-one commented on GitHub (Aug 23, 2022): I've published version 1.22.2,which now supports node recovery. See #142 for more info Let me know if that works. Also, if you are sure you are not auto-scaling your app in the cloud, let me know if you find a reproducible way to "break" a node!

gitea-mirror commented

2026-05-23 08:27:25 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 5, 2022):

Closing the issue again, feel free to reopen if this is still an issue!

@appy-one commented on GitHub (Sep 5, 2022): Closing the issue again, feel free to reopen if this is still an issue! [![Sponsor AceBase](https://user-images.githubusercontent.com/26569719/168233053-8e56b243-4140-40ab-9a30-4cb3cc149bfe.svg)](https://github.com/sponsors/appy-one) [![Spread the word](https://user-images.githubusercontent.com/26569719/169265089-3d593555-e1ad-4390-986b-877ac2c38a47.svg)](https://twitter.com/intent/tweet?button=&url=https://github.com/appy-one/acebase&text=I'm+using+@AcebaseRealtime+in+my+project+to+make+my+life+easier!&button=) [![contribute](https://user-images.githubusercontent.com/26569719/169265318-30c4c6a5-7c89-46a0-a7a2-ef433a8192f4.svg)](https://github.com/appy-one/acebase#contributing)

gitea-mirror commented

2026-05-23 08:27:25 -06:00

Author

Owner

@neilsutcliffe commented on GitHub (Sep 8, 2022):

Hi. I keep on getting a different issue, but still general corruption. I'm having to back up my database any time I change it. Might look into collections, but I am not doing complex things with arrays...

Either way, I end up corrupting the database when working with Next.js. It could be the hot-reloading is creating multiple connections to the database, which causes this issue.

CorruptRecordError: CORRUPT RECORD: key "img" in "/image/77f9d37ee3c03f1d702a20b11e08cee22210ae5f[0]" (@22,369) refers to address @22,323 which was already used to read "/image/2ffeb7f6c7b5ca0606af6178a7009fb08d69ac4d". Recursive or repeated reading has been prevented.
    at new NodeReader (admin/node_modules/acebase/src/storage-acebase.js:2340:27)
    at loadChildValue (admin/node_modules/acebase/src/storage-acebase.js:2583:40) {
  record: [NodeAddress],
  key: 'img'
}

img in this case is a URL

I've taken to storing different tables in different databases allowing me to revert only one if needed.

@neilsutcliffe commented on GitHub (Sep 8, 2022): Hi. I keep on getting a different issue, but still general corruption. I'm having to back up my database any time I change it. Might look into collections, but I am not doing complex things with arrays... Either way, I end up corrupting the database when working with Next.js. It could be the hot-reloading is creating multiple connections to the database, which causes this issue. ``` CorruptRecordError: CORRUPT RECORD: key "img" in "/image/77f9d37ee3c03f1d702a20b11e08cee22210ae5f[0]" (@22,369) refers to address @22,323 which was already used to read "/image/2ffeb7f6c7b5ca0606af6178a7009fb08d69ac4d". Recursive or repeated reading has been prevented. at new NodeReader (admin/node_modules/acebase/src/storage-acebase.js:2340:27) at loadChildValue (admin/node_modules/acebase/src/storage-acebase.js:2583:40) { record: [NodeAddress], key: 'img' } ``` img in this case is a URL I've taken to storing different tables in different databases allowing me to revert only one if needed.

gitea-mirror commented

2026-05-23 08:27:26 -06:00

Author

Owner

@appy-one commented on GitHub (Sep 10, 2022):

@neilsutcliffe You have to prevent multiple concurrent AceBase instances to the same database to prevent corruption. Reuse 1 single AceBase instance throughout your app to prevent this. Hot reloading should not be an issue, but having 2+ separate instances in your code both altering the same database will corrupt the db.

@appy-one commented on GitHub (Sep 10, 2022): @neilsutcliffe You have to prevent multiple concurrent `AceBase` instances to the same database to prevent corruption. Reuse 1 single `AceBase` instance throughout your app to prevent this. Hot reloading should not be an issue, but having 2+ separate instances in your code both altering the same database will corrupt the db.

gitea-mirror commented

2026-05-23 08:27:27 -06:00

Author

Owner

@neilsutcliffe commented on GitHub (Sep 14, 2022):

@neilsutcliffe You have to prevent multiple concurrent AceBase instances to the same database to prevent corruption. Reuse 1 single AceBase instance throughout your app to prevent this. Hot reloading should not be an issue, but having 2+ separate instances in your code both altering the same database will corrupt the db.

It's 2 seperate instances with 2 different database files.

However it is reinitialising on hot reloading...

I think I might have to look more into how next.js does this and determines what to recompile. There has to be mechanisms to prevent it from rebuilding.

@neilsutcliffe commented on GitHub (Sep 14, 2022): > @neilsutcliffe You have to prevent multiple concurrent `AceBase` instances to the same database to prevent corruption. Reuse 1 single `AceBase` instance throughout your app to prevent this. Hot reloading should not be an issue, but having 2+ separate instances in your code both altering the same database will corrupt the db. It's 2 seperate instances with 2 different database files. However it is reinitialising on hot reloading... <img width="609" alt="image" src="https://user-images.githubusercontent.com/13319277/190145338-aff193bf-f2b2-442d-beea-caf36ce9700f.png"> I think I might have to look more into how next.js does this and determines what to recompile. There has to be mechanisms to prevent it from rebuilding.

Rows
Columns

[GH-ISSUE #42] TypeError: Unknown chunk type 91 while reading record at #33