test: sig verification panic on nil pub key

[rootulp]

Closes #4847

[rootulp]

Finally able to repro the exact error stack trace

--- FAIL: TestSigVerificationDecorator (0.03s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x8 pc=0x1022e76e0]

goroutine 27 [running]:
testing.tRunner.func1.2({0x1044c6a60, 0x106f8d3f0})
	/Users/rootulp/sdk/go1.23.8/src/testing/testing.go:1632 +0x1bc
testing.tRunner.func1()
	/Users/rootulp/sdk/go1.23.8/src/testing/testing.go:1635 +0x334
panic({0x1044c6a60?, 0x106f8d3f0?})
	/Users/rootulp/sdk/go1.23.8/src/runtime/panic.go:791 +0x124
github.com/cosmos/cosmos-sdk/x/auth/tx.(*wrapper).GetSigningTxData(0x14001a24880)
	/Users/rootulp/go/pkg/mod/github.com/celestiaorg/[email protected]/x/auth/tx/adapter.go:63 +0x540
github.com/cosmos/cosmos-sdk/x/auth/ante.SigVerificationDecorator.AnteHandle({{_, _}, _}, {{0x104bc9c30, 0x10706c840}, {0x104be9390, 0x140014c4d00}, {{0x0, 0x0}, {0x0, ...}, ...}, ...}, ...)
	/Users/rootulp/go/pkg/mod/github.com/celestiaorg/[email protected]/x/auth/ante/sigverify.go:322 +0x734
github.com/celestiaorg/celestia-app/v4/app/ante_test.TestSigVerificationDecorator(0x14000492b60)
	/Users/rootulp/git/rootulp/celestiaorg/celestia-app/app/ante/ante_test.go:43 +0x39c
testing.tRunner(0x14000492b60, 0x104b60af0)
	/Users/rootulp/sdk/go1.23.8/src/testing/testing.go:1690 +0xe4
created by testing.(*T).Run in goroutine 1
	/Users/rootulp/sdk/go1.23.8/src/testing/testing.go:1743 +0x314
FAIL	github.com/celestiaorg/celestia-app/v4/app/ante	0.656s
FAIL

[rach-id]

so the plan is to wait and see if the cosmos-sdk's upstream changes this to stop panicking in this case and pull their changes?

what about syncing? if I understand correctly, when syncing with the new sdk, this panics and it shows in the logs, should we document somewhere that these are expected logs (for node operators not to bombard us with questions about this?)

[rootulp]

so the plan is to wait and see if the cosmos-sdk's upstream changes this to stop panicking in this case and pull their changes?

Yes.

what about syncing? if I understand correctly, when syncing with the new sdk, this panics and it shows in the logs, should we document somewhere that these are expected logs (for node operators not to bombard us with questions about this?)

I don't think the logs will occur during syncing because a tx with a nil pubkey in the signature data shouldn't be included in any blocks. The log will only appear for new txs that enter a node's mempool. We could still document it somewhere