Skip to content

ThinkWatch Core 0.64.1

Choose a tag to compare

@github-actions github-actions released this 08 Oct 02:58
· 42 commits to main since this release
1ddda16

This release lifts a 2 MiB limit on request bodies that the gateway never meant to have. A conversation holding a few inline screenshots passed 2 MiB and was refused from then on, compaction requests included, so the session could not be compacted back under the limit (#295).

Upgrade notes

  • The control-plane protocol version (CONTROL_API_VERSION) stays at 40: ThinkWatch Lite 2026.10.7 connects to 0.64.1, and a server can be upgraded on its own.
  • The request store's schema is unchanged: upgrading from 0.64.0 keeps the request history.
  • The configuration format is unchanged.
  • Message codes, compared with 0.64.0:
    • New: gw.request.body_declared_too_large, gw.request.body_over_limit, gw.request.body_unreadable.
    • Removed: gw.request.body_too_large, replaced by the first two: one for a declared length over the limit, which names the length the client declared, and one for a body found over the limit while reading, which has no size to name.

Request size. The gateway's only limit on a request body is now its own 256 MiB. The body used to be read by the web framework before the gateway saw the request, under the framework's default 2 MiB limit: anything larger got a plain-text 413 Failed to buffer the request body, was not in the client's error format, and left no record.

The body is now read only after the source-address check, the key check and the POST check pass, so a connection that is not allowed in can no longer make the gateway hold its body in memory first. A request whose Content-Length is already over the limit is refused without reading the body. The limit is enforced on the bytes actually received, so a Content-Length that understates the body does not get around it. An oversized request is answered with 413 in the client's own error format (request_too_large for Anthropic clients), and x-thinkwatch-error: request.

Downloads

Platform Binary Archive for server installation
Linux, x86_64 twcore-x86_64-unknown-linux-gnu twcore-x86_64-unknown-linux-gnu.tar.gz
Linux, aarch64 twcore-aarch64-unknown-linux-gnu twcore-aarch64-unknown-linux-gnu.tar.gz
macOS, Apple silicon twcore-aarch64-apple-darwin —
Windows, x64 twcore-x86_64-pc-windows-msvc.exe —
Windows, ARM64 twcore-aarch64-pc-windows-msvc.exe —

Each file is published with a .sha256 file beside it. A Linux archive contains twcore, the systemd unit twcore.service and LICENSE. ThinkWatch Lite includes its own copy of twcore; the files here are for running core separately, such as on a server.

Server installation

On Linux (x86_64 or aarch64), the install script sets up twcore as a systemd service. This installs 0.64.1:

curl -fsSL https://raw.githubusercontent.com/ThinkWatchProject/ThinkWatch-Core/main/scripts/install.sh | sudo sh -s -- --version 0.64.1

An installation made with the script switches to 0.64.1 with:

sudo twcore upgrade --version 0.64.1 --restart

Configuration, the remote control port and connecting ThinkWatch Lite are described in docs/server.md.

Verifying a download

A .sha256 file holds the SHA-256 of the file followed by its name. With both files in the current directory, on Linux:

sha256sum -c twcore-x86_64-unknown-linux-gnu.tar.gz.sha256

On macOS:

shasum -a 256 -c twcore-aarch64-apple-darwin.sha256

On Windows, in PowerShell, the following prints True when the binary matches:

(Get-FileHash .\twcore-x86_64-pc-windows-msvc.exe).Hash -eq (Get-Content .\twcore-x86_64-pc-windows-msvc.exe.sha256).Split()[0]

The install script and twcore upgrade check the SHA-256 themselves.

What's Changed

  • Read the request body after the source and key checks, with the gateway's 256 MiB as the only limit, v0.64.1 by @fylorn in #296

Full Changelog: v0.64.0...v0.64.1