solana-orderbook: account orders endpoint

[squadgazzz]

Description

Front-end requested to implement the GET /api/v1/account/{owner}/orders endpoint already for the demo. The Solana version serves the same shape: one owner's orders with their fill state, newest first, offset/limit pagination with the EVM defaults and bounds, and the verbatim LIMIT_OUT_OF_BOUNDS rejection.

Deliberate differences: the owner is a base58 public key (InvalidOwner in the API's error shape on a malformed one), and each order carries the fill state from solana.order_pda, same as the single-order endpoint. The query rides the existing solana_orders_user_creation index.

Changes

• GET /api/v1/account/{owner}/orders with EVM pagination semantics
• orders_by_owner read in the db layer, newest first with the fill-state join

How to test

New ignored postgres test for the pagination and a unit test for the parameter rejections.

Related issues

BE-259

[linear-code]

BE-259

[github-actions]

Reminder: Please consider backward compatibility when modifying the API specification.
If breaking changes are unavoidable, ensure:

• You explicitly pointed out breaking changes.
• You communicate the changes to affected teams (at least Frontend team and SAFE team).
• You provide proper versioning and migration mechanisms.

---

Caused by:

• crates/solana-orderbook/openapi.yml

[claude]

Claude finished @squadgazzz's task in 1m 41s —— View job

---

PR Review: account orders endpoint

• Read diff and surrounding conventions
• Compare against the EVM get_user_orders endpoint for parity
• Verify DB query, index usage, and error handling
• Verify tests and OpenAPI schema references

Overall: Clean, well-scoped PR that mirrors the EVM endpoint closely. The DB query rides the solana_orders_user_creation index (owner, creation_timestamp DESC), reuses the single-order fill-state join and dto::Order::new, and the OpenAPI Order/Pubkey/Error refs all resolve. The pagination test correctly asserts newest-first ordering, owner isolation, and the fill-state join; the API test covers both parameter rejections. Bind order (LIMIT $2 OFFSET $3 ↔ owner/limit/offset) is correct.

One non-blocking parity note posted inline:

• offset/limit are i64 here vs u64 in the EVM endpoint; a negative offset is silently clamped to 0 instead of being rejected. Switching to u64 would make the contract identical and drop the .max(0).

Nothing blocking from my side.
· solana-orderbook/account-orders

[MartinquaXD]

this could reference the constants to never go out of sync with them.