releasePartial() sends the wrong on-chain key to the contract — a raw UUID instead of the numeric onChainId every other operation uses

Aperta
  • Qualcosa non va?
#300 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@PINYOPATTANAWASANPORN ci sta già lavorando.

Dal 13/10/2026.

  • #484 di @PINYOPATTANAWASANPORN — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
typescript
Ambito
backend, blockchain

Direzione di ricerca

Start in src/escrow/escrow.service.ts and compare releasePartial() with release() and refund(), which all use this.onChainKeyFor(escrow). Read onChainKeyFor to see how onChainId becomes a bigint ('9100' -> 9100n). Then open escrow.service.spec.ts; the releasePartial block expects ['milestone-1', 'GRECIPIENT', 300_000_000n], while release/refund expect 9100n. Done means the invoke uses onChainKeyFor(escrow) and the spec assertions match. Linked PR #484 is already open.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Every other Soroban call in EscrowService resolves the on-chain identifier through onChainKeyFor(escrow) (src/escrow/escrow.service.ts), which returns the numeric escrow.onChainId persisted at fund time (or a deterministic derived fallback): poolWithdraw, refund, and invokeRelease (backing both release() and splitRelease()) all use it.

releasePartial() alone does not do this:

const result = await this.invokeOnLockedEscrow(
  escrow,
  'releasePartial',
  () =>
    this.soroban.invoke(
      'release_partial',
      [
        escrow.milestoneId ?? escrow.bountyId ?? escrow.id,
        recipientAddress,
        this.toStroops(amount),
      ],
      this.contractOpts(escrow),
    ),
);

The first argument is escrow.milestoneId ?? escrow.bountyId ?? escrow.id — a raw UUID string, not the bigint numeric key the escrow was actually fund()-ed under. Since escrow::fund stores the on-chain record keyed by issue_id: u64 (see the SorobanClientService docstring), and every other release/refund path looks that same record up via the numeric onChainId, releasePartial is passing a completely different, non-numeric key. This isn't just an architecture gap (already covered by #160/#162, which flag that release_partial has no real contract counterpart at all) — it's a narrower, independently-fixable inconsistency: even once a real release_partial-equivalent entrypoint exists, this code would still be looking the escrow up under the wrong identifier compared to the fund/release/refund calls for the very same row.

The bug is baked into the test suite as expected behavior — escrow.service.spec.ts asserts soroban.invoke is called with ['milestone-1', 'GRECIPIENT', 300_000_000n] (the raw milestoneId string) even though the same fixture (lockedEscrow()) sets onChainId: '9100', which every other describe block (release, refund) correctly expects to see converted to 9100n.

Fix: change releasePartial's invoke call to use this.onChainKeyFor(escrow) like every sibling method, and update the test fixture/expectations to match.

Lingua principale
TypeScript
Stelle
2
Fork
90
Merge medio
31m
PR unite (30g)
20

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MergeFi/backend

Tutte le issue di MergeFi/backend

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.