Skip to content

Unify browser and CI transaction paths via REST v1 endpoints #255

@Andre-Diamond

Description

@Andre-Diamond

Why the Current CI Misses Browser Bugs

The CI suite drives the REST v1 API. The browser never calls most of those endpoints — it uses a completely different stack:

Layer CI path Browser path
Auth JWT Bearer token (authenticateSignerWithMnemonic) NextAuth session cookie
Transaction building Server-side in REST handler (MeshTxBuilder on Node) Client-side in React component (MeshTxBuilder in browser)
Persistence POST /api/v1/addTransaction or createPendingMultisigTransaction tRPC transaction.createTransaction
Submission (1-of-N) REST handler auto-submits useTransaction.ts submits locally then persists

A bug introduced in stake.tsx's MeshTxBuilder setup, or in the tRPC createTransaction handler, will never be caught by the current CI.


The Two Independent Gaps

Understanding the gaps separately makes the solution space clearer:

Gap 1 — Transaction building: The MeshTxBuilder construction in React components (stake.tsx, registerDrep.tsx, updateDrep.tsx, retire.tsx, ProxyControl.tsx via offchain.ts) is untested. A bad UTxO selection, wrong certificate type, or missing field produces an on-chain failure — CI never exercises any of this.

Gap 2 — Persistence path: The browser persists transactions via tRPC transaction.createTransaction. The CI uses POST /api/v1/addTransaction. If the tRPC handler has a bug (schema mismatch, DB constraint, wrong state) the CI won't catch it.

Both gaps can be addressed independently, and different options address them to different degrees.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions