Build Trustless Work End-to-End Test Suite

[Kalchaqui]

Issue: Build Trustless Work End-to-End Test Suite

Depends on: Existing webhook sync (src/webhooks/webhooks.service.ts) and escrow write helper (src/internal-trustless/escrow-write.helper.ts)

Task Description

Develop an end-to-end test suite covering the integration between Thalos and Trustless Work (TW), validating that Agreements stay synchronized across their lifecycle under both success and failure scenarios. This must build on the existing Jest + supertest setup, not introduce a new framework.

Background / Current State

Verified against main: synchronization is driven by inbound webhooks (POST handled in webhooks.service.ts), which map TW events to agreement status changes:

• escrow.funded → funded
• escrow.released → completed
• escrow.disputed / dispute.created → disputed
• contract.completed → completed
• contract.cancelled → cancelled
• milestone updates → milestone sync

Resilience today is a per-request withRetry() helper, not a persistent retry queue. Tests must target this actual mechanism.

Deliverable

End-to-end *.spec.ts tests covering the Trustless Work integration, runnable via the existing jest / test:integration scripts.

Requirements

Validate:

• Agreement creation → escrow write via escrow-write.helper.ts (deployer/single-release, deployer/multi-release).
• Contract linking (PATCH /agreements/:id/link-contract) and by-contract lookup.
• Status synchronization via webhook events (escrow.funded, escrow.released, escrow.disputed, contract.completed, contract.cancelled).
• Milestone synchronization (agreement.milestone_updated / escrow.milestone_updated).
• HMAC signature verification in verifySignature() (valid + invalid signatures).
• withRetry() behavior on transient failures (succeeds after N attempts; surfaces error after exhaustion).
• Idempotency (a duplicate webhook event does not double-apply a status change).
• Activity logging entries produced by synced transitions.

Validation System

• Each webhook event drives the final agreement to the expected status.
• Invalid HMAC signatures are rejected; valid ones pass.
• A transient-failure simulation recovers via withRetry() and a persistent failure surfaces the error.
• Replaying the same event twice leaves the status unchanged after the first apply.

Technical Requirements

• Mock external TW calls (relayToTrustless) and Supabase — do not hit live services.
• Simulate network/provider failures to exercise withRetry().
• Validate synchronization integrity (final agreement status matches the event).
• Executable in CI via pnpm test (respect testRegex: .*\.spec\.ts$).

Additional Notes

The original issue referenced a "retry queue" — there is no persistent queue in main, only in-request retry. Scope tests to the real webhook + withRetry design; if a durable queue is later added, extend the suite then.

Testing (required)

• E2E spec: full lifecycle create → link-contract → funded → released/completed passes.
• Signature spec: valid vs invalid HMAC handled correctly.
• Retry spec: recovery after N transient failures and error after exhaustion.
• Idempotency spec: duplicate webhook event does not double-apply.

Proof of Completion (required)

• Link the merged PR.
• Paste the passing pnpm test output showing the TW integration specs.
• Attach a short summary/log mapping each webhook event to its resulting status assertion.

[ceshez]

Hi! I’d like to apply for issue #68.

I can build the Trustless Work end-to-end test suite using the existing Jest and supertest setup, covering agreement creation, contract linking, webhook-driven status and milestone synchronization, HMAC verification, retry behavior, idempotency, and activity logging.

I’ll mock Trustless Work and Supabase, test the real withRetry() mechanism without introducing a new queue or framework, and include the required full-lifecycle, signature, retry, and duplicate-event scenarios. I’ll also provide the passing pnpm test output and a clear mapping of each webhook event to its expected agreement status.

[grantfox-oss]

🦊 GrantFox — @ceshez has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #68)
2. Your PR will be reviewed by the Thalos-Infrastructure maintainers

Good luck! Track your progress on GrantFox.

[ManuelJG1999]

🎉 Congratulations @ceshez ! This issue has been assigned to you.

Before you start, make sure you understand the requirements. If you have any questions, ask us in our community chat:
https://t.me/ThalosOSSCommunity

Please keep us updated on your progress. If there's no activity or communication within 48 hours, the issue may be reassigned to another contributor.

Happy coding, and thanks for contributing to Thalos! 🐉

[ceshez]

🎉 Congratulations @ceshez ! This issue has been assigned to you.

Before you start, make sure you understand the requirements. If you have any questions, ask us in our community chat: https://t.me/ThalosOSSCommunity

Please keep us updated on your progress. If there's no activity or communication within 48 hours, the issue may be reassigned to another contributor.

Happy coding, and thanks for contributing to Thalos! 🐉

Thank you very much. I will begin working on this right away and will let you know if I have any questions.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@ceshez's PR #108 was approved and merged by @Kalchaqui.

🏆 @ceshez: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (331 total points). Track your full progress on GrantFox.

👏 Great work, @ceshez! Keep contributing to Thalos-Infrastructure.