Skip to content

Fix: 3 issues (#1018, #1027, #1028) - #1126

Merged
Sulex45 merged 2 commits into
stellarkit-lab-devtools:mainfrom
Mozez155:simple/1018-1027-1028
Oct 23, 2026
Merged

Sulex45 merged 2 commits into
stellarkit-lab-devtools:mainfrom
Mozez155:simple/1018-1027-1028

Conversation

@Mozez155

Copy link
Copy Markdown
Contributor

Closes #1018
Closes #1027
Closes #1028

Issues

#1018 Write tests for POST /utils/decode-transaction with all common operation types

POST /utils/decode-transaction maps XDR operations to readable shapes but edge cases around uncommon operation types are untested. Write tests covering: a changeTrust operation decodes with type: "changeTrust", asset, and limit fields, a manageOffer operation decodes with type: "manageOffer", selling, buying, amount, and price fields, a setOptions operation decodes with type: "setOptions" and the relevant options fields, and a transaction with multiple operations decodes all of them in order.

Acceptance Criteria: All four test cases exist and pass using real XDR fixtures. Tests are in tests/routes/utils.decodeTransaction.test.js. All tests pass with npm test

#1027 Write a docs/claimable-balances-guide.md explaining all claimable balance endpoints

The API has multiple claimable balance endpoints but they have no dedicated documentation. Developers building claiming tools need guidance on the difference between GET /account/:id/claimable-balances, GET /account/:id/claimable-balances/eligible, GET /account/:id/claimable-balance-summary, and GET /claimable-balances/by-sponsor/:address. Write a docs/claimable-balances-guide.md covering all these endpoints.

Acceptance Criteria: Guide covers all claimable balance endpoints with curl examples and sample responses. Explains the difference between eligible and pending balances. Includes a worked example of checking and claiming a balance. Linked from README under Documentation section.

#1028 Write tests for GET /account/:id/offer-exposure exposure aggregation and liquidity risk

GET /account/:id/offer-exposure aggregates open offer data but has no tests. Write tests covering: an account with 3 open sell offers for the same asset returns one sellingExposure entry with offerCount: 3, liquidityRisk is "high" when more than 80% of a balance is in open offers, an account with no open offers returns empty arrays and liquidityRisk: "low", and a non-existent account returns a 404.

Acceptance Criteria: All four test cases exist and pass. Tests mock the Stellar SDK offers and account responses. Tests are in tests/routes/account.offerExposure.test.js. All tests pass with npm test.

Summary

The decode-transaction endpoint emits snake_case operation types (change_trust, manage_sell_offer, set_options) via toSnakeCaseType, so tests must assert those rather than the camelCase names in the issue text. XDR fixtures should be generated at test time with TransactionBuilder using Networks.TESTNET to stay valid. For offer-exposure tests, inspect the actual route in src/routes/account.js to confirm the exact response field names (sellingExposure, offerCount, liquidityRisk) and the 404 error path before writing assertions; mock server.offers().forAccount(...).call() and server.loadAccount accordingly. The claimable balances guide should reflect the real response shapes from src/routes/claimableBalances.js and the account claimable-balance routes.

Changes

  • Create tests/routes/utils.decodeTransaction.test.js covering POST /utils/decode-transaction. Build real XDR fixtures with the @stellar/stellar-sdk TransactionBuilder (Networks.TESTNET) for: (1) a changeTrust operation, asserting the decoded operation has type 'change_trust' (snake_case per formatDecodedOperation) plus line/asset and limit fields; (2) a manageOffer (manageSellOffer) operation, asserting type 'manage_sell_offer' with selling, buying, amount, and price fields; (3) a setOptions operation, asserting type 'set_options' and the relevant options fields (e.g. signer, masterWeight, thresholds); (4) a transaction with multiple operations, asserting operationCount and that operations decode in order with correct indices. Use supertest against the app, POST the base64 envelope as { xdr }, and assert on the success envelope's data.operations. Note the endpoint emits snake_case types (change_trust, manage_sell_offer, set_options) rather than camelCase, so assert accordingly. Ensure all tests pass with npm test. (tests/routes/utils.decodeTransaction.test.js)
  • Create docs/claimable-balances-guide.md documenting all claimable balance endpoints: GET /account/:id/claimable-balances, GET /account/:id/claimable-balances/eligible, GET /account/:id/claimable-balance-summary, and GET /claimable-balances/by-sponsor/:address. For each endpoint include purpose, query params (limit, cursor, order, fresh as applicable), a curl example, and a sample JSON response matching the route shapes (by-sponsor returns { balanceId, asset, amount, claimants, createdAt } with meta pagination; eligible categorises balances as eligible/not-yet-claimable/expired). Explain the difference between eligible and pending balances, and include a worked example of checking eligibility and then claiming a balance (building and submitting a claimClaimableBalance transaction). Reference the evaluate endpoint GET /claimable-balances/:id/evaluate/:accountId where useful. (docs/claimable-balances-guide.md)
  • Add a link to the new Claimable Balances Guide under the README Documentation section, e.g. '- Claimable Balances Guide - All claimable balance endpoints with curl examples, sample responses, eligible vs pending explanation, and a worked claim example'. Place it alongside the other endpoint guides (e.g. near the Account Endpoints Guide entry). (README.md)
  • Create tests/routes/account.offerExposure.test.js for GET /account/:id/offer-exposure. Mock the Stellar SDK via jest.mock on ../src/config/stellar (server.loadAccount and server.offers().forAccount().call()) and any cache service. Cover: (1) an account with 3 open sell offers for the same asset returns a single sellingExposure entry with offerCount: 3; (2) liquidityRisk is 'high' when more than 80% of a balance is committed to open offers; (3) an account with no open offers returns empty arrays and liquidityRisk: 'low'; (4) a non-existent account (loadAccount rejects with a 404) returns HTTP 404. Use supertest against the app and assert on the success envelope. Ensure all tests pass with npm test. (tests/routes/account.offerExposure.test.js)

Mozez155 and others added 2 commits October 20, 2026 12:53
@Sulex45
Sulex45 merged commit 3bef848 into stellarkit-lab-devtools:main Oct 23, 2026
0 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants