Unified invoice DTO and OpenAPI-style contract published for FE and BE #446

Activity

1. CemAyyildiz

   added

   enhancementNew feature or requestNew feature or request

   help wantedExtra attention is neededExtra attention is needed

   Maybe RewardedIssue may be eligible for a GrantFox rewardIssue may be eligible for a GrantFox reward

   GrantFox OSSIssue tracked in GrantFox OSSIssue tracked in GrantFox OSS

   on Sep 14, 2026
2. rudrasatani13 commented on Sep 14, 2026

   

   rudrasatani13

   on Sep 14, 2026

   Contributor

   More actions

   I'd like to take this one.

   The create-path validation introduced for #436 is already a shared module used by both sides, so I would generalise that rather than start a second type system:

   • Schemas in shared/: one module defining create, get, list, cancel, verify and stats, each with its request shape, response shape and a parser that returns typed data or a typed error. Field names and requiredness stay in one place, so a rename cannot land on one side only.
   • One error envelope: { code, message, field? } with a stable code list, mapped once from the API's rejection reasons and once from the client's, so the same invalid payload produces the same code and message on both sides. The existing create-parity tests keep passing and become one case in the wider contract test.
   • Validation at the edge: handlers parse inbound bodies with the shared parser instead of ad-hoc checks, and the frontend forms and API client consume the same parsers, so a payload that passes locally cannot fail server-side.
   • Contract tests that fail when a required field, a response key or an error code diverges: a fixture per endpoint driven through the parser, plus a test that compares the handler's response shape against the schema. They run under the repo's existing test commands so CI picks them up unchanged.
   • In-memory MVP stays valid: the DTO layer sits above both the in-memory and Postgres paths, so nothing about the demo server changes except that its responses are now schema-checked.

   I would land it in slices rather than one large PR: shared schemas plus the error envelope first, then handlers, then the frontend client and forms, then the contract tests, keeping each mergeable on its own.

   For context on how much is already there: #457 moved create validation into shared code and both sides now use it, #440 scoped the dashboard queries, and #442 made the wallet session a single source of truth across create, pay and dashboard.
3. davidtanko48-create commented on Sep 15, 2026

   

   davidtanko48-create

   on Sep 15, 2026 – with GrantFox OSS

   More actions

   I’m interested in this issue and confident I can contribute effectively. I’ve reviewed the requirements and can deliver a clean, reliable solution within the expected timeframe.
4. s6pa1rta3n-lab commented on Sep 17, 2026

   

   s6pa1rta3n-lab

   on Sep 17, 2026

   Contributor

   More actions

   I am working on this implementation: establishing unified invoice request/response contracts and shared error envelopes in shared/, connecting handlers and frontend client/forms, ensuring backward compatibility with the MVP server, and adding contract tests.
5. Rodrigoue9 commented on Sep 18, 2026

   

   Rodrigoue9

   on Sep 18, 2026

   More actions

   Hi @CemAyyildiz, applying to resolve #446.

   Relevant Experience

   • Senior Full-Stack TypeScript engineer specialized in shared-schema monorepos, Zod contract validation, and unified DTO design across Express and Next.js App Router.

   Proposed Implementation

   1. Shared Contract Schemas (\shared/):
      • Expand the shared module to define complete request/response schemas for all invoice actions: \create, \get, \list, \cancel, \�erify, and \stats.
      • Export strongly-typed TypeScript interfaces derived directly from the schemas (\z.infer).
   2. Standardized Error Envelope:
      • Define a shared error contract { code: ErrorCode, message: string, field?: string }\ with an exhaustive error taxonomy enum, ensuring client and server map failures to identical error representations.
   3. End-to-End Validation:
      • Enforce schema parsing on inbound Express request bodies before entering controller handlers.
      • Wire frontend forms and the client API layer to consume the exact same validation schemas, preventing client-server drift.
   4. Preserve In-Memory & DB Compatibility:
      • Implement the DTO layer at the boundary level so the in-memory MVP server continues operating seamlessly without regressions.
   5. Contract Parity Tests:
      • Add contract test suites that run under existing test commands (
        pm test), validating each endpoint fixture against its schema and asserting that breaking field changes fail CI immediately.

   Estimate: PR ready in 24-48h (structured in clean, reviewable commits).
6. Ranjeet2063 commented on Oct 4, 2026

   

   Ranjeet2063

   on Oct 4, 2026

   Contributor

   More actions

   Hi,

   I have experience with similar implementations and would like to take this on.

   Solution overview:

   1. Audit storage layout and state invariants ensuring strict auth guards.
   2. Implement deterministic state transitions with safe checked arithmetic.
   3. Add hermetic unit and regression tests covering authorized, unauthorized, and boundary edge cases.
   4. Profile instruction and CPU/gas limits under Soroban host environment.

   Please assign this to me if the plan looks good. Thanks!
7. woahwhattheheck commented on Oct 9, 2026

   

   woahwhattheheck

   on Oct 9, 2026

   Contributor

   More actions

   /claim #446

   I am the original contributor of the completed issue #446 implementation in #571. Please review this existing PR for acceptance and any eligible GrantFox OSS reward under published program terms. If an award is approved, please confirm its actual amount, allocation, payment route and expected settlement date. No fixed amount or prior payment is being asserted.