Skip to content

Only the error paths of one tool are tested #421

Closed

Description

@Miracle656

Background

tests/mcp.test.ts has four tests, all on paid_call:

should map signature expiration ledger error to ERR_EXPIRED_AUTHORISATION
should map missing trustline error to ERR_MISSING_TRUSTLINE
should map 402 rejected error to ERR_PAYMENT_REJECTED
should return successfully on a successful call

bazaar_search has no tests at all — not the query path, not the empty-result
path, not the non-2xx path. ListTools is never exercised, so a malformed tool
schema would ship unnoticed.

The four that exist also construct errors as plain strings, which is what makes
L215's text-matching fragility invisible to the suite.

What to build

  • Cover bazaar_search: with and without a query, empty results, non-2xx, a
    malformed body.
  • Cover ListTools: the advertised tools, and that each inputSchema is valid.
  • Cover the unknown-tool path.
  • Where an upstream error is simulated, use a shape resembling what the real
    library throws.

Acceptance criteria

  • bazaar_search has tests for success, empty, non-2xx and malformed body
  • ListTools is exercised and each schema validated
  • The unknown-tool path is covered
  • Simulated errors resemble real ones
  • The four existing tests still pass

Drips Wave · Complexity: Intermediate · 150 points


Repo: Divinity-Labs/Lens. The MCP server is src/mcp/server.ts
(BazaarMcpServer) with error codes in src/mcp/codes.ts. It is started by
npm run mcp:server → examples/mcp-server/run.ts, and there is an agent
example at examples/mcp-server/agent.ts. Tests are tests/mcp.test.ts.

Run the tests: npm test. The tests are vitest, not jest. A single file
is npx vitest run tests/mcp.test.ts.

Load test (prices) is already failing on main. Not your PR.

This surface signs with a real mainnet key. examples/mcp-server/run.ts
requires MCP_AGENT_SECRET_KEY_MAINNET and builds a signer for
stellar:pubnet. Anything you change here can move real money, so prefer
failing closed, and never log, echo or test with a real secret key.

Never elide an address, a contract id or a key in code, comments or
fixtures. A previous batch shortened a contract id and five contributors
invented plausible-looking ids to fill the gap. Write it in full or not at all.

An agent is the least able caller to notice a wrong answer. It will reason
over whatever it is handed, confidently. Prefer a structured error over a
best-effort result.


Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

Activity

  1. optimism932-dotcom commented on Oct 17, 2026

    @optimism932-dotcom

    @optimism932-dotcom has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Kindly assign this task to me.i can fix it.

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @optimism932-dotcom to this issue.

  2. KingDavid9999 commented on Oct 17, 2026

    @KingDavid9999

    @KingDavid9999 has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi maintainer, I'd very much appreciate the opportunity to work on this issue.
    Having reviewed the acceptance criteria, I'm confident that I'd be able to have a PR up shortly after being assigned.
    Kindly assign this issue to me.
    Thank you!

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @KingDavid9999 to this issue.

  3. gpromise7077-web commented on Oct 17, 2026

    @gpromise7077-web

    @gpromise7077-web has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi maintainer, I'd like to work on this issue, pls assign me to this task

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @gpromise7077-web to this issue.

  4. muazumikail1915-create commented on Oct 17, 2026

    @muazumikail1915-create

    @muazumikail1915-create has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    hi maintainer
    i will like to work on this issue prior to the experience i have

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @muazumikail1915-create to this issue.

  5. AGWAM001 commented on Oct 17, 2026

    @AGWAM001
    Contributor

    @AGWAM001 has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    I'd love to take this issue on. I'm a full-stack developer with experience across Drips Waves4-7.
    My stack include rust, Soroban, Solidity, and TypeScript. I can deliver a clean, tested, and well-documented solution within 5 hours of assignment.
    Jovial to start immediately

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @AGWAM001 to this issue.

  6. solaawojobi00-bit commented on Oct 17, 2026

    @solaawojobi00-bit
    Contributor

    @solaawojobi00-bit has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    This one fits what I work on.

    tests/mcp.test.ts currently only tests paid_call error scenarios, leaving bazaar_search, ListTools schema validation, and unknown tool dispatch completely uncovered.

    I will expand tests/mcp.test.ts using Vitest to thoroughly test bazaar_search across query, empty, non-2xx, and malformed responses. I will also test ListTools to ensure each advertised tool schema validates properly, add coverage for unhandled tool names, and mock upstream errors matching library shapes without touching mainnet keys.

    Kindly assign to me.

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @solaawojobi00-bit to this issue.

  7. pristabel commented on Oct 17, 2026

    @pristabel

    @pristabel has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi, I'd like to take this one on. I'll first go through the existing code and patterns in the relevant files to keep my changes consistent with how the rest of the project is built. I'll address everything in the requirements and acceptance criteria, write tests where they make sense, and confirm the build and tests pass locally before submitting the PR

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @pristabel to this issue.

  8. drips-wave commented on Oct 17, 2026

    @drips-wave

    Congratulations, @AGWAM001! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on October 22, 2026.

    🧑‍💻 @AGWAM001: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

    Warning

    When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

    🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

    🌊 Happy Wave 🌊

  9. AGWAM001 commented on Oct 23, 2026

    @AGWAM001
    Contributor

    Follow-up on the review of #524 (now closed): re-audited against main after #521 landed as c55a980, and the coverage this issue asks for is already on main, so nothing is left to open here.

    Measured on main (89bc678), comparing test bodies rather than titles:

    • tests/mcp.test.ts + tests/mcp-http.test.ts: 104 passed, tsc --noEmit exit 0.
    • bazaar_search: discovery routing (list + query), empty-result ERR_NO_RESULTS, non-2xx / unparseable / transport ERR_SERVICE_UNREACHABLE, the SSRF guard, argument validation.
    • ListTools: advertised tool set, an SDK-parseable result, a valid inputSchema per tool.
    • unknown tool: structured ERR_UNKNOWN_TOOL naming the valid tools, plus the name bound/sanitise case.
    • paid_call error paths: the four legacy cases now use the shapes the real libraries throw, and classifyPaidCallError is covered directly.

    The ~9,900-line gap in #524 was that branch re-adding what #521 had already shipped; its head also failed to parse (src/mcp/server.ts:886, duplicated handleHttpRequest parameters), which is why it could not simply be merged.

    The one thing still live is split out to #607: .env.example declared MCP_MAX_PAYMENT_PRICE= twice, so the "Ceiling per paid_call" comment described a line dotenv never applied.

  10. AGWAM001 commented on Oct 23, 2026

    @AGWAM001
    Contributor

    Correction to my own comment above: I wrote that "the four legacy cases now use the shapes the real libraries throw". That was not true. Three of the four still used invented material, and the fourth cannot be made faithful without a source change. #608 rewrites the three so they can be:

    • ERR_EXPIRED_AUTHORISATION — Transaction signature expired. Signature expiration ledger 123 is less than current ledger 125 appears in no installed package. @x402/fetch 2.24.0 rethrows a scheme failure as Failed to create payment payload: <cause> (dist/esm/index.mjs:48), and @stellar/stellar-sdk 13.3.0 says The transaction has expired (lib/webauth/utils.js:124, thrown as InvalidChallengeError).
    • ERR_PAYMENT_REJECTED — a rejected payment does not throw: the wrapper pays, retries and returns the seller's second 402, so it arrives as a Response with an x402 error body, not as an Error.
    • success — a settled call echoes X-PAYMENT-RESPONSE, which src/mcp/ledger.ts:163 base64-decodes. The old stand-in had no headers property at all, so no test ever reached that code path.

    The trustline case is left as a plain string, and it wants its own issue. Horizon answers op_no_trust with BadResponseError, whose result_codes live at err.response.extras.result_codes, while extractStructuredSignal reads err.result_codes (src/mcp/codes.ts:118). I constructed a real new BadResponseError(message, problemDocument) from @stellar/stellar-sdk 13.3.0 and ran it through classifyPaidCallError: it returned ERR_BAD_REQUEST, not ERR_MISSING_TRUSTLINE — the instance's own keys are constructor, response, name, so result_codes is never on the error at all. That means the structured branch is one a real Horizon failure can never reach, and every genuine trustline failure is classified by text matching today. main's own describe('BazaarMcpServer paid_call error classification') block sets err.result_codes directly, so it is asserting against a field no dependency populates.

    That is a source bug, and a tests-only PR cannot fix it without dressing a behaviour change as a fixture, so #608 leaves src/ alone. Verified there: tsc --noEmit exit 0, npm run build exit 0, 75 passed in tests/mcp.test.ts, full suite 1445 passed | 1 skipped, and check-dropped-tests sees 1340 cases on both sides.

  11. drips-wave commented on Oct 23, 2026

    @drips-wave

    This issue has been completed by @AGWAM001 as part of the Stellar Wave Program's 10th Wave 🥳

    😎 @AGWAM001: You earned 150 Points for completing this issue! Once the Wave's rewards are finalized, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

    🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.

  12. added a commit that references this issue on Oct 23, 2026
    07189a7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions