[Bug] Demo app never reconciles milestone status against real on-chain state

[collinsezedike]

Summary

JobsContext.tsx's submitMilestone/disputeMilestone/voteOnMilestone/finalizeMilestone each fire a real transaction against packages/tholos-sdk, then optimistically set the local milestone status by assuming the call succeeded exactly as expected. None of them read the contract back. docs/src/INTEGRATION.md (lines 146-160) documents the correct pattern for this exact situation: poll get_assertion_state(id), or watch events, neither of which this app does.

Scope

• Add a way to read real assertion state (get_assertion_state) into lib/tholos.ts, alongside the existing assert_outcome/dispute/resolve/finalize calls.
• After each action in JobsContext.tsx, or on a polling interval for any milestone with an assertionId, reconcile local status from the real read instead of assuming success.
• A milestone whose challenge window has passed uncontested should reflect that it's now eligible for finalize, driven by the real state, not by silence in the local optimistic status.

Proposed approach

Add getAssertionState(id) to lib/tholos.ts wrapping the SDK's get_assertion_state. In JobsContext.tsx, after a successful action call, immediately re-read state and set status from that read rather than a hardcoded guess (e.g. voteOnMilestone currently sets released/returned from the return value of resolveAssertion alone). For milestones with an assertionId and no terminal status yet, poll on an interval (or on demand via a refresh action) so status advances even without the user having just taken an action, e.g. once someone else's finalize call lands, or once a challenge window quietly expires.

[xtep103]

Hey , I have gone through the details of the issue and i am capable of resolving it, I would love to be assigned to work on it ASAP. Thanks in advance

[JohnArayaE]

I would like to work on this issue because milestone status should reflect the real on-chain assertion state rather than optimistic local assumptions, especially when other participants or challenge-window timing can change the outcome independently of the current user. I can add a getAssertionState(id) wrapper alongside the existing Tholos SDK calls, reconcile milestone status from the contract after successful actions, and add polling or refresh handling for non-terminal milestones with an assertionId so eligibility for finalization and externally-triggered state changes are reflected accurately.

[Sharon-dev-create]

I have dealt with this exact problem and resolved it so I'm confident that I can provide solution to this to.

[samueldoo]

Hello Maintainer, I’d love to take ownership of this issue and submit a high-quality pull request once completed.

[collinsezedike]

@JohnArayaE assigning this to you, your read on the actual bug (optimistic status vs real assertion state) was the most accurate of the applicants here. Go ahead and dig in, let me know if anything's unclear.

[grantfox-oss]

🦊 GrantFox — @JohnArayaE has been assigned to this issue!

Next steps:

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

Good luck! Track your progress on GrantFox.

[JohnArayaE]

@collinsezedike Changes are up in #179, ready for your review.