Daemon can become permanently non-responsive after repeated operations

[c-wri]

Observed

After repeated paste/use, the daemon can enter a state where operations keep failing until clipreg.service is manually restarted. Restarting immediately restores operation. The journal currently provides no useful failure signal for the stuck state.

Violated invariant

A bounded operation must return the daemon to command-ready state or fail observably. An alive-but-permanently-unusable daemon violates the runtime liveness contract.

Investigation / acceptance

• Instrument transaction phase/progress without logging clipboard payloads.
• Identify whether the stall is Wayland dispatch, data-source lifecycle, transfer completion, transaction cleanup, socket/client state, or another bounded state transition.
• Add the lowest-level durable regression that reproduces the root cause.
• Stress repeated paste/grab operations on supported COSMIC while recording NRestarts and post-loop command responsiveness.
• Service restart is containment only and does not close this issue.

Current corrective evidence

PR #2 identified the escaped root cause: stable_snapshot_current() could synchronously receive ClipReg's own restored selection instead of routing through the existing self-owned clone boundary, deadlocking the single Wayland event loop.

The corrective checkpoint has:

• a regression that failed on the pre-fix beta and passes after correction;
• green Ubuntu 24.04 canonical CI;
• live Pop!_OS/COSMIC Terminal stress evidence with 39 traced operations;
• repeated snapshot-clipboard-clone-owned / snapshot-primary-clone-owned progress;
• bounded terminal-grab failures returning through transaction-finish rather than poisoning daemon state;
• NRestarts remaining 0 -> 0;
• post-loop clipreg list, clipreg doctor, and clipreg app responsiveness.

The liveness acceptance conditions are therefore satisfied by the candidate. Keep this issue open until PR #2 is integrated, then close it as fixed.

Separate terminal input/selection defects exposed during the same run are tracked independently in #5 and #6 and remain blockers for v0.2.0-rc.1; they do not invalidate the liveness evidence because those failures were bounded and command-ready state was preserved.

This issue blocks v0.2.0-rc.1 promotion until the corrective PR is integrated.

[c-wri]

Investigation checkpoint for PR #2:

The repeated-operation liveness failure has a concrete escaped path. snapshot_current() already protects the single-threaded daemon from receiving a selection that ClipReg itself owns by cloning held MIME data. stable_snapshot_current() bypasses that boundary and calls the offer-receive path directly.

After paste restoration, ClipReg may be the current clipboard/primary source. A subsequent stable snapshot can therefore synchronously wait for data whose source_send() callback must run on the same blocked Wayland event loop.

A direct lifecycle regression is now on draft PR #2. The first CI checkpoint is intentionally red and proves the current beta behavior on Ubuntu 24.04: all earlier gates pass, then [8/12] runtime lifecycle regressions fails with stable snapshot rejected a self-owned selection.

The corrective checkpoint remains on the same PR. Issue #1 stays open until live COSMIC repeated-operation qualification shows flat NRestarts and post-loop command responsiveness; service restart remains containment only.

[c-wri]

Corrective checkpoint is now green.

• PR Prevent self-owned selection deadlock after paste #2 head: e445ee5e99d216ee2c9d42d3352eac049905cb46
• Local supported-workstation make check: PASS, including the new runtime lifecycle regression, ASan/UBSan, real wayland-scanner/libwayland-client build, and binary self-test.
• GitHub Ubuntu 24.04 CI / Check: PASS.
• Tracked-state-clean verification: PASS.

The root cause remains the self-owned stable-snapshot deadlock described above: stable_snapshot_current() bypassed the existing snapshot_current() self-ownership boundary and could synchronously receive ClipReg's own restored selection on the same event loop that must service source_send().

Issue #1 remains open. Per docs/qualification.md, the next acceptance gate is live COSMIC stress evidence: repeated paste/grab operations, flat NRestarts, command responsiveness after the loop, and review of the new phase-only diagnostics. Service restart is not acceptance.

[c-wri]

Live COSMIC liveness evidence — corrective PR #2

Tested the corrective checkpoint e445ee5e99d216ee2c9d42d3352eac049905cb46 on Pop!_OS 24.04 / COSMIC Terminal (com.system76.CosmicTerm).

Observed run:

• 39 traced grab/paste operations in the captured journal window.
• Repeated paste operations completed after the first transaction through the intended self-owned paths (snapshot-clipboard-clone-owned and, when applicable, snapshot-primary-clone-owned).
• Multiple failed terminal grabs timed out with ETIMEDOUT, but each returned through transaction-finish; later commands remained usable without service restart.
• NRestarts remained 0 -> 0.
• Post-loop clipreg list, clipreg doctor, and clipreg app all returned successfully.
• No alive-but-permanently-unusable state recurred.

This provides the live supported-environment evidence for the liveness invariant. Issue closure should follow integration of PR #2 rather than using restart/containment as proof.

A separate terminal-grab input defect was exposed during the same run: generic Copy probing / function-key use can leak terminal escape-sequence fragments (for example visible ...~ text) and some grabs time out. That does not invalidate the liveness result because the failures were bounded and the daemon returned command-ready, but it must be tracked independently before RC promotion.