A failed vault release strands a resolved task's funds permanently, with no retry path

[N-thnI]

Description

Add a recovery path for tasks that resolved successfully but whose vault release failed.

Problem Statement

src/contracts/voting.rs:22 swallows vault failures by design:

match result {
    Ok(_)  => events::emit_vault_release_success(env, task_id),
    Err(_e) => events::emit_vault_release_failed(env, task_id),
}

This is the deliberate fix for #134 / #184 ("Vault release_funds call is not fault-isolated — a broken vault can permanently block task resolution"), and as a DoS fix it is correct: resolution must not be hostage to a broken vault.

But it traded a denial of service for silent fund-stranding, and the recovery half was never built.

When the release fails, the task is still marked is_done, resolved_at is set, and the task is persisted by storage::set_active_task. The release block is guarded by !t.is_done, so it can never run again for that task.

Searching every .rs file in the crate, release_funds appears only in voting.rs, events.rs and gas.rs. There is no admin retry entrypoint, no pending-release record, and no re-trigger path anywhere in the contract.

So a vault that is paused, underfunded, misconfigured, mid-upgrade, or simply out of gas for one subcall loses that task's payout permanently. The only trace is a vault_release_failed event, which nothing consumes on-chain.

Given the protocol exists to make contributor payouts verifiable, a resolved task whose funds silently never move is a direct failure of its core promise.

Proposed Changes

• Record failed releases in storage (e.g. DataKey::PendingRelease(task_id)) when try_release_vault_funds fails, rather than only emitting an event
• Add an entrypoint to retry release for a task with a recorded pending release, callable by the admin or permissionlessly (the vault call is idempotent per task and re-attempting is safe)
• Clear the pending-release record on a successful retry and emit a success event
• Expose a read method listing task IDs with outstanding pending releases, so operators can detect stranded funds without replaying events

Technical Implementation Scaffolding

• Target Repository: vero-core-contracts
• Target Path: src/contracts/voting.rs, src/contracts/vault_ops.rs, src/types.rs
• Branch Naming: feat/issue--vault-release-retry
• Authority Context: Security-sensitive — permanent loss of contributor payouts

Acceptance Criteria

• A task whose vault release fails still resolves (the Vault release_funds call is not fault-isolated — a broken vault can permanently block task resolution #134 / fix: isolate vault release_funds call to prevent task resolution DoS #184 behaviour is preserved unchanged)
• That task is recorded as having an outstanding release
• A retry after the vault recovers releases the funds and clears the record
• A retry for a task with no pending release is rejected
• Retrying twice does not double-release

Definition of Done

• Reviewed by lead maintainer
• Pull request merged via verified status check

---

This issue is self-contained. Everything it needs already exists on main; it does not wait on any other issue. Deliver the change and its tests in one PR.

[MAN7A-afk]

Hello maintainer, Please Assign me to this task

[Ranjeet2063]

Hi maintainers, I'd love to take this on!

Execution Plan for A failed vault release strands a resolved task's funds permanently, with no retry path:

• Smart Contract Architecture: Implement A failed vault release strands a resolved task's funds permanently, with no retry path with explicit auth checks (require_auth), clean DataKey storage, and zero-overflow arithmetic.
• Exhaustive Testing: Add unit tests asserting both happy-path states and unauthorized reverts with exact ContractError variants.
• Green CI: Verify zero clippy warnings and 100% test coverage locally before opening the PR.

Why assign me?

• Proven Proof-of-Work: [Test] Add integration test suite for double-vote validation #1 contributor on Mova Store (28 merged Web3 PRs) and official ElizaOS contributor.
• Fast Turnaround: Dedicated to shipping a tested, production-grade PR within 12–24 hours.
• Zero Maintainer Burden: Self-documenting code with green CI and tests included so you don't spend time debugging.

Excited to contribute—please assign this to me and I'll push a clean PR shortly!

[ZacLou]

I have experience with Soroban recovery-path design and payment safety tests. I would add a persistent outstanding-release record, expose an idempotent retry entrypoint that can be called by the admin or permissionlessly, clear it on success, add a read method for stranded releases, and include regression tests for failed/succeeded retries and double-retry prevention. I can deliver a focused PR within 1–2 days after assignment.

[guptakumarranjeet150]

Hi maintainers,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Implement A failed vault release strands a resolved task's funds permanently, with no retry path with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Testing & Verification: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.
• Delivery: Ready to ship a thoroughly tested PR within 12–24 hours with passing CI.

Looking forward to contributing—please feel free to assign!

[shobhamerabacha-star]

Hello @maintainers,

I would love to take this on. My planned approach:

• Implement A failed vault release strands a resolved task's funds permanently, with no retry path with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

I am ready to start immediately—please assign this to me!