Escrow create accepts payer == beneficiary and the id-reuse rule is undocumented
Los mantenedores suelen responder en 1 día
@KuchiMercy ya está trabajando en esto.
Desde el 18/10/2026.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- postgresql, typescript
- Área
- backend, documentation, testing
Línea de trabajo
Start by locating the escrow create implementation and its existing has(&key) duplicate-id check. Add validation so payer == beneficiary returns InvalidParties, then add tests for identical parties and document in the README that IDs remain single-use for the life of the contract. Run the escrow test suite and verify the README rule.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
create accepts payer == beneficiary, which produces an escrow where one party can release or refund at will, and the duplicate-id check only tests has(&key). That is correct for id reuse today, but the rules aren't documented (an id that was Released can never be reused, which affects backend id derivation).
Proposed change
Reject payer == beneficiary with a new InvalidParties error, document the id uniqueness rule and retention in the README, and add tests for both cases.
Acceptance criteria
-
createwith identical payer and beneficiary returns the new error. - README states that ids are single-use for the life of the contract.
- Lenguaje dominante
- TypeScript
- Estrellas
- 16
- Forks
- 225
- Merge medio
- 8 h 4 min
- PR fusionados (30 d)
- 61
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de DistinctCodes/ManageHub
-
bug contract soroban-contract
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
DistinctCodes/ManageHub#2029 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
backend contract documentation soroban-contract
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DistinctCodes/ManageHub#2028 ·
Los mantenedores suelen responder en 1 día
-
Add an end-to-end local sandbox for contracts (standalone network, deploy, call) to the repo docsAbiertocontract documentation soroban-contract
Dificultad 3/5 1-2 días Aptitud para principiantes 76/100
DistinctCodes/ManageHub#2027 ·
Los mantenedores suelen responder en 1 día
-
backend contract documentation NestJS soroban-contract
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
DistinctCodes/ManageHub#2026 ·
Los mantenedores suelen responder en 1 día
-
Contracts have no shared ABI/interface fixture used by both the Rust tests and the backend clientAbiertobackend contract enhancement NestJS soroban-contract
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
DistinctCodes/ManageHub#2025 ·
Los mantenedores suelen responder en 1 día
Todos los issues de DistinctCodes/ManageHub
Issues similares
-
engine-rs P3 review-deferral wasm
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
maniator/verticopolis#1154 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
telerik/kendo-react#3861 ·
Los mantenedores suelen responder en 1 día
-
[bug]: use-mobile.ts uses pixel logic, causing UI state de-sync with Tailwind CSS rem breakpointsAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
task
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100