Client stopped working on Archlinux after python-xxhash update

[al-paca]

Running this on Arch Linux with the clipcascade-bin (3.2.0) package from the AUR

After a system update that bumped python-xxhash from 3.8.1 to 4.0.1, ClipCascade stopped syncing clipboard content entirely - every send and every receive fails, logging:

ERROR - Failed to send data: Strings must be encoded before hashing
ERROR - Failed to receive data: Strings must be encoded before hashing

This happens regardless of whether E2E encryption is enabled or disabled, and with any clipboard content (including a fresh, simple string), which pointed to something running unconditionally in the send/receive path rather than the cipher logic.

It loos to stem from this in clipboard/clipboard_manager.py, hash_clipboard()

def hash_clipboard(clipboard: str) -> int:
    return xxhash.xxh64(clipboard).intdigest()

This passes a raw str directly to xxhash.xxh64() without encoding it to bytes first. Older versions of python-xxhash tolerated this; as of 4.0.0 the library enforces bytes-only input and raises TypeError: Strings must be encoded before hashing when given a str. Since has_clipboard_changed() (which calls this) runs at the very start of both send() and _receive() in stomp_ws/stomp_manager.py, before the cipher_enabled check, it breaks all clipboard sync unconditionally once the newer xxhash is installed — no encryption or content variable required to reproduce it.

Fix for me was making this change.

def hash_clipboard(clipboard: str) -> int:
    return xxhash.xxh64(clipboard.encode("utf-8")).intdigest()

Applying that one-line change locally (/usr/share/clipcascade/clipboard/clipboard_manager.py) immediately restores normal sync.

[dev-aitkd]

Confirming this on CachyOS (Arch-based), clipcascade-bin 3.2.0 from the AUR, after python-xxhash went 3.8.1 → 4.0.1 (upgraded here 2026-08-21). Identical symptom — every send and receive fails with Strings must be encoded before hashing, and the one-line fix in hash_clipboard() restores sync immediately.

Two things to add that might help when patching this:

1. The P2P path is affected too, not just STOMP. The issue text cites stomp_ws/stomp_manager.py, but has_clipboard_changed() is also the first call in both P2P transfer paths on main:

• ClipCascade_Desktop/src/p2p/p2p_manager.py:719 — in _send()
• ClipCascade_Desktop/src/p2p/p2p_manager.py:824 — in _receive()

My log showed Server mode: P2S, so P2P/P2S users hit exactly the same failure. Worth confirming the fix covers both transports.

2. The fix is behavior-preserving — hashes don't change. I checked the old and new library directly, since previous_clipboard_hash is compared across the upgrade:

xxhash 3.8.1:  xxh64('abc').intdigest()   -> 4952883123889572249
xxhash 4.0.1:  xxh64(b'abc').intdigest()  -> 4952883123889572249

So 3.x was silently UTF-8 encoding, and encoding explicitly reproduces the old value exactly. No cache invalidation or cross-version concern.

One small suggestion on the patch itself — guarding on the type keeps it working if a non-str is ever passed in, and is compatible with both xxhash 3.x and 4.x:

@staticmethod
def hash_clipboard(clipboard: str) -> int:
    if isinstance(clipboard, str):
        clipboard = clipboard.encode("utf-8")
    return xxhash.xxh64(clipboard).intdigest()

Also worth noting for other Arch users landing here: since python-xxhash 4.0.1 is already in extra, any pacman -Syu will pull it in and break the client, so this will likely generate more reports until 3.2.1 ships.

[Joeckli]

Confirmed on two Linux clients with python-xxhash 4.x.

I encountered the same issue with ClipCascade after an update. Clipboard monitoring and the WebSocket connection remained functional, but every clipboard change on the sending client resulted in:

ERROR - Failed to send data: Strings must be encoded before hashing

Environment:

• CachyOS / Arch-based, KDE Plasma Wayland
• Python 3.14.7
• python-xxhash 4.0.1
• Fedora 44 KDE Wayland as the second ClipCascade client
• Self-hosted ClipCascade server in P2S mode

I reproduced the underlying problem directly:

import xxhash

xxhash.xxh64("CACHY-TEST").intdigest()
# TypeError: Strings must be encoded before hashing

xxhash.xxh64("CACHY-TEST".encode("utf-8")).intdigest()
# works

I applied the following local change to clipboard/clipboard_manager.py:

@staticmethod
def hash_clipboard(clipboard: str) -> int:
    if isinstance(clipboard, str):
        clipboard = clipboard.encode("utf-8")
    return xxhash.xxh64(clipboard).intdigest()

After restarting ClipCascade, the error disappeared and clipboard synchronization immediately worked again in both directions between the CachyOS and Fedora clients.

I used the isinstance() check rather than unconditional .encode() so the function remains safe if it is ever passed an already byte-like value.

This appears to be a compatibility issue introduced by python-xxhash 4.0.0+, which no longer accepts str input.