crashes due to (code: -32603)

[opsecx]

Hey, undexer still randomly crashes when I run it. Most often doesn't stay up for very long (minutes) when it's reached end of current chain. Below is the error I'm getting. (I run the indexer using ./undexer index)

`✔ �Block�=> Latest block in DB: 183920
⋯ �NamadaChain�Querying block height
file:///home/(user)/undexer/fadroma/packages/namada/pkg/fadroma_namada.js:740
��������const ret = new Error(getStringFromWasm0(arg0, arg1));
��������������������^

Error: response error

Caused by:
����Internal error: could not find results for height #183921 (code: -32603)

Location:
����/home/(user)/.cargo/registry/src/index.crates.io-6f17d22bba15001f/flex-error-0.4.4/src/tracer_impl/eyre.rs:10:9
����at file:///home/(user)/undexer/fadroma/packages/namada/pkg/fadroma_namada.js:740:21
���at logError (file:///home/(user)/undexer/fadroma/packages/namada/pkg/fadroma_namada.js:125:18)
����at imports.wbg.__wbg_new_796382978dfd4fb0 (file:///home/(user)/undexer/fadroma/packages/namada/pkg/fadroma_namada.js:739:66)
����at fadroma_namada.wasm.js_sys::Error::new::h7fe894f285d4ba99 (wasm://wasm/fadroma_namada.wasm-007ab76e:wasm-function[2795]:0x1824ed)
����at fadroma_namada.wasm.fadroma_namada::decode::Decode::block::h547b973124f15a71 (wasm://wasm/fadroma_namada.wasm-007ab76e:wasm-function[34]:0x25f90)
����at fadroma_namada.wasm.decode_block (wasm://wasm/fadroma_namada.wasm-007ab76e:wasm-function[1682]:0x1717ce)
����at Decode.block (file:///home/(user)/undexer/fadroma/packages/namada/pkg/fadroma_namada.js:399:18)
����at NamadaBlock.fromResponses (file:///home/(user)/undexer/fadroma/packages/namada/NamadaBlock.ts:39:51)
����at NamadaBlock.fetchByHeight (file:///home/(user)/undexer/fadroma/packages/namada/NamadaBlock.ts:30:17)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

	Node.js v20.18.0`

(sorry about ugly formatting)

[egasimus]

while true; do ./undexer index; done

[egasimus]

This has remained on our radar and will be fixed in the upcoming release of 4.0.00 (which has been powering https://shielded.live/ for some weeks).

Note that 4.0.0 will depend on Docker; we had to leverage Docker's iptables integration to make sync pausable, in order to get correct values for past data (see namada-net/namada#3810)

[opsecx]

Have you looked into whether running an archive node ("indexer = kv" in namada's config.toml file) would allow this data to persist in the node? Previously I believe some other indexers required that setting to be set in rpc?

[opsecx]

I'm not sure I understand why the workaround fraccaman describes in the referenced issue requires leveraging docker? Would be great if they gave it some priority on their end to get this into the node software.

[opsecx]

I'm glad to see it fixed of course, though from my usecase it's a problem if it requires me to run the dockered postgres (with node also?)

[egasimus]

Primarily the node needs to be dockerized, on a docker virtual network, alongside two sidecar containers. DB, indexer, and api can still run outside of docker, as long as the env vars are set correctly to point to the containers

[egasimus]

Fixed in v4.

[opsecx]

Primarily the node needs to be dockerized, on a docker virtual network, alongside two sidecar containers. DB, indexer, and api can still run outside of docker, as long as the env vars are set correctly to point to the containers

can you say more about why it needs to be dockerized? at least I can run my own db which is good. Will give it a spin sometime and see how it looks from this end.