Protected content: resume playback after pending Wallet approval

Analysis baseline and required implementation base

The analysis was performed on fix/0.7.1-security at 54355973e737f018e7d898a74449f9b04aaef26c. The findings below apply to that reviewed revision; their applicability to the latest protected-content workflows remains unverified.

The product owner has designated PR #70 as the latest protected-content feature/workflow line and the required base for this work.

PR metadata checked on 2026-09-29: PR #70 is open, with head feat/protected-content-listing-buy at d181ffd2af202b6551f2bf0e7e0688d229c3c5ef, stacked on PR #62. This is a planning snapshot; resolve the latest head again when work starts. No code revalidation against PR #70 has been performed for this ticket yet.

Before implementation:

1. Resolve PR feat(protected-content): buy from any live offer, found by link or in Explore #70's current head branch and commit, and record the exact revision checked.
2. Re-verify the finding against that revision, tracing the current Runtime and viewer flow and adding a focused reproduction where appropriate.
3. Record whether the issue is still present, already resolved, or changed in scope. If resolved, document the evidence and close the issue without a redundant fix.
4. If confirmed, implement the fix on top of PR feat(protected-content): buy from any live offer, found by link or in Explore #70 and submit it as a stacked PR targeting PR feat(protected-content): buy from any live offer, found by link or in Explore #70's head branch. If that parent changes, revalidate and update the stack before merging. Integrate the fix after or together with its parent.

This ticket remains deferred from the current release plan. Revalidation on PR #70 is a prerequisite to starting a fix.

Problem

The protected-video player treats the Runtime's new pending Wallet approval result as a terminal playback failure.

Runtime persists the prepared recipient and exact Wallet request, then returns an error envelope with the message Runtime custody viewer release is pending exact Wallet approval. The player throws every error envelope, sets failed = true, and displays an error overlay. It has no approval-specific resume action or polling path.

Approving in Wallet alone therefore does not resume playback. Closing and reopening can change the launch/session binding and cause the previous pending ceremony to be cleaned up and replaced.

Release scope and priority

• Deferred backlog: outside the current release plan, as requested by the product owner.
• Suggested priority: P2.
• Category: workflow / frontend-Runtime contract integration.

Evidence

Reviewed fix/0.7.1-security at 54355973e737f018e7d898a74449f9b04aaef26c against upstream/0.7.1-dev at 6c61c990b9a1d0f2c1b00ee6f5f091d3354cafac.

• Runtime persists pending approval and returns an error.
• Player throws provider error envelopes.
• Player sets terminal-looking failed state.
• Playback funnels open failures into fail().

The player behavior predates this diff; the integration defect arises from adding a resumable pending Runtime response without corresponding consumer handling.

Evidence level: source trace, independently checked. No installed reproduction or fix has been performed.

Reproduction to add

1. Open eligible protected video in Elacity Player with a managed Wallet requiring approval.
2. Runtime returns the pending approval response.
3. Observe the player error overlay.
4. Approve the exact request in Wallet.
5. Observe that playback does not resume in the existing player.

Test this independently from the companion recipient/release expiry mismatch so timing failures do not hide the missing UI transition.

Expected behavior and implementation direction

Represent pending approval as a typed response distinct from terminal failure. Show the approval state and allow the existing viewer to resume the same Runtime ceremony after approval, preserving launch authority, prepared recipient, and exact request identity.

Use the existing product interaction patterns. Handle denial, expiry, revocation, and close explicitly, with bounded polling or an explicit resume action.

Acceptance criteria

• Re-verify the finding on PR feat(protected-content): buy from any live offer, found by link or in Explore #70 and record its exact head commit and evidence before implementing.
• If still present, base the fix on PR feat(protected-content): buy from any live offer, found by link or in Explore #70 and submit it as a stacked PR targeting that feature branch.
• Runtime exposes a typed pending state and the player recognizes it.
• Pending approval shows an actionable waiting state.
• Approval resumes playback in the same viewer without reopening.
• Resume preserves the original recipient, Wallet request, and session authority.
• Repeated resume attempts remain idempotent and do not create duplicate approvals.
• Denial, expiry, revocation, and viewer close settle the pending lifecycle correctly.
• Tests cover pending → approved → playing and all terminal outcomes.
• Installed approval-to-playback evidence is recorded on the fixed revision.

Related

• Protected content: align expiry deadlines when resuming Wallet approval #81 — Protected content: align expiry deadlines when resuming Wallet approval.
• Protected-content UI/UX parity gaps vs feat/dkms-esp-port: protect any file type, Creator app, open-through-decryption #42 — broader protected-content UI/UX work.
• Installed acceptance: one Runtime, two principals, mint → buy → play (ELACITY-2300) #47 — installed mint → buy → play acceptance.