fix: getAccountInfo handle not found account

[lunargon]

Fix: align GetAccountInfo with Solana RPC specification for non-existent accounts

Summary

Per the Solana JSON-RPC Specification for getAccountInfo, when an account does not exist on-chain, the node returns

{"context": {...}, "value": null}

with no RPC error.

Previously, GetAccountInfoWithOpts intercepted out.Value == nil and returned nil, ErrNotFound. This PR updates GetAccountInfoWithOpts to return (out, nil) (where out.Value == nil), matching standard Solana RPC behavior.

Test

• go test ./rpc -v -run "TestClient_GetAccount.*"
• go vet .

[greptile-apps]

Greptile Summary

The PR aligns GetAccountInfo with Solana RPC null-value semantics and updates internal consumers to handle missing accounts explicitly. The functional nil-account fix is complete, but the replacement commit remains unsigned.

• Returns a successful account-info response with a nil Value for nonexistent accounts.
• Preserves ErrNotFound behavior in decoding helpers and CLI commands.
• Adds missing-account tests and guards address-lookup-table decoding.
• Still does not satisfy the verified-commit requirement.

Confidence Score: 4/5

The PR should not merge until its sole current commit is signed and verified.

The account-not-found handling now protects the previously affected callers, but replacing the earlier unsigned commit with another unsigned commit leaves the repository's verified-commit requirement unsatisfied.

Files Needing Attention: The PR commit metadata for f621e61 requires attention.

Important Files Changed

Filename	Overview
rpc/getAccountInfo.go	Changes raw account lookup to preserve null RPC values while decoding helpers retain ErrNotFound behavior; the code fix is sound, but the containing commit is unsigned.
rpc/client_test.go	Adds focused coverage for null account-info responses and not-found behavior in decoding helpers.
cmd/slnc/cmd/get_account.go	Prevents the previously reported nil dereference by checking both the response and Value.
cmd/slnc/cmd/token_get_mint.go	Prevents the previously reported nil dereference and returns ErrNotFound for a missing mint.
programs/address-lookup-table/address-lookup.go	Rejects null account values before attempting address-lookup-table decoding.

_{Reviews (4): Last reviewed commit: "fix: getAccountInfo handle not found acc..." | Re-trigger Greptile}

[greptile-apps]

Nil account value reaches callers

When an account does not exist, GetAccountInfoWithOpts now returns a nil error with out.Value == nil; existing get-account and token-get-mint callers check only the error and then dereference Value, causing a panic.

[greptile-apps]

Commit lacks verified signature

Commit 4436687da9752fa937a68662a6ca8996cb6266de has no verifiable signature, so this pull request does not satisfy the repository requirement that commits be signed and verified.

Context Used: Request changes if the commits are not signed (ver... (source)

[greptile-apps]

Replacement commit remains unsigned

The sole commit in the current pull-request range has no signature, so the pull request still violates the repository requirement that every commit be signed and verified and cannot be merged in its current form.

Context Used: Request changes if the commits are not signed (ver... (source)

[koriyoshi2041]

Reviewed at f621e616. Returning the RPC envelope preserves the response context for a protocol-level value: null, while the decoding helpers and CLI/address-table consumers retain explicit not-found handling instead of dereferencing the nil value.

Local verification passed:

go test ./rpc/... ./programs/address-lookup-table/... ./cmd/slnc/cmd/... -count=1
git diff --check origin/main...HEAD

The code change looks good at this head. The remaining merge gate is repository policy: the replacement commit is still not GitHub-verified, and CONTRIBUTING requires verified signatures.

[lunargon]

@koriyoshi2041 Hello. Hope you have a nice day. I try to force push for add verified signatures. And in this PR have only 1 commit with verified

Please check this. Thank you so much.

[koriyoshi2041]

Confirmed: GitHub now reports commit f621e616 as verified (reason: valid). The code head is unchanged from the one I tested, so my earlier source review and focused test result still apply. The signature-policy blocker is resolved from my side.