Panic - Ghostdag store - uppon accessible an unexisting key

[IzioDev]

Describe the bug
I'm not sure what RPC calls, with what parameters caused this panic, but it panicked upon trying to access a non-existent store key.

Logs

2025-07-27 14:05:28.029+00:00 [INFO ] Accepted 12 blocks ...14d01a25feb23d83d8f8bc53f2068c9838852cfbd3ec58ea3fd633276e54e440 via relay
2025-07-27 14:05:28.529+00:00 [ERROR] thread 'tokio-runtime-worker' panicked at consensus/src/model/stores/ghostdag.rs:124:67: called `Result::unwrap()` on an `Err` value: KeyNotFound(GhostdagCompact/0/7e252aef5f000b761446988eca57e5e76608dec5048182294d2080c24fca0d5d)
Exiting...
thread 'tokio-runtime-worker' panicked at consensus/src/model/stores/ghostdag.rs:124:67:
called `Result::unwrap()` on an `Err` value: KeyNotFound(GhostdagCompact/0/7e252aef5f000b761446988eca57e5e76608dec5048182294d2080c24fca0d5d)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior
I expect kaspad not to panic, possibly by not assuming the key exists or by doing a lookup before using keys.

Desktop (please complete the following information):

• OS: Debian
• Kaspad version: v1

[davdroman]

This sounds serious.

If I'm reading correctly: there is an RPC call that will crash any public node it's called on by simply passing an arbitrary key as a parameter?

@someone235 @coderofstuff would you mind taking a look at this please?

[IzioDev]

This hasn't happen again since I encountered it.

I've added rust backtrace environment variable in case this happens again in the future to have a better view of what's happening.