Open Validatus opened 1 month ago
Did the panic happen during the restart or during regular operation?
This panic happened somewhere deep in the DB we use. My current hypothesis is that the node was ungracefully terminated causing DB corruption
Did the panic happen during the restart or during regular operation? During "regular operation".
This panic happened somewhere deep in the DB we use. My current hypothesis is that the node was ungracefully terminated causing DB corruption
We share the same working hypothesis. Although the datacenter has denied any sudden power loss or server shutdowns, we’ve observed that during ongoing construction work at the site, these issues tend to occur intermittently. This suggests that the node might have been ungracefully terminated, potentially leading to the database corruption.
We’re currently working to reproduce the error to confirm this theory and will update you once we have more information.
Celestia Node version
Semantic version: v0.16.0 Commit: 6744f648649ebb5fee1b27faf7aca96ecf4519b2
OS
Rocky Linux 9.4
Install tools
We are building binaries from source to ensure complete control over the compilation process. All needed tools are present on the system.
Others
There are no known resource limitations.
Steps to reproduce it
celestia bridge start --metrics.tls=true --metrics --metrics.endpoint otel.celestia.observer --p2p.network celestia --node.store /storage/.celestia-bridge
Expected result
The expected result is to have the Celestia bridge node fully operational and syncing to the latest network head. This ensures that the node is connected to the network, validating and relaying blocks in real time, and staying up to date with the current state of the blockchain. This allows the bridge node to play its role in cross-chain communication or light client verification within the Celestia network.
Actual result
The panic message "index out of range [3] with length 0" suggests that the program tried to access an index in an array that doesn't exist, causing the program to crash.
Relevant log output
Is the node "stuck"? Has it stopped syncing?
The log indicates a runtime panic that occurred while using BadgerDB, specifically during the initialization of BadgerDB tables, causing the binary to crash.
Notes
We can easily provide additional logs if necessary. Should you require more detailed information or further diagnostics to help resolve the issue, just let us know, and we’ll be happy to share any logs that can assist with troubleshooting.