chore(release): prepare v0.2.1 #29

Merged

jlxq0 merged 2 commits from release-v0.2.1 into main

2026-08-26 16:02:59 +00:00

jlxq0 commented

2026-08-26 15:11:32 +00:00

Owner

Version bump and changelog for v0.2.1, carrying #28's admitted-initialize counter.

An instrument that exists and is not deployed answers nothing, and #21's claim spans three servers of which this is the only one that can produce a count. That is why this ships as its own release rather than waiting.

Version bump and changelog for v0.2.1, carrying #28's admitted-initialize counter. An instrument that exists and is not deployed answers nothing, and #21's claim spans three servers of which this is the only one that can produce a count. That is why this ships as its own release rather than waiting.

jlxq0 added 1 commit

2026-08-26 15:11:32 +00:00

chore(release): prepare v0.2.1

CI / cargo (pull_request) Failing after 14m28s

Details

CI / docker (pull_request) Has been cancelled

Details

287a005c41

jlxq0 added 1 commit

2026-08-26 16:00:54 +00:00

feat(auth): log the X-Forwarded-For entry count, never the entries

CI / cargo (pull_request) Successful in 43s

Details

CI / docker (pull_request) Successful in 51s

Details

518aa078c9

Both deployments set CALDAV_MCP_TRUSTED_PROXY_HOPS=0, and parse_client_ip
returns None the moment hops is 0, before it reads the header. So the per-token
last-used record has carried no client IP for the life of the deployment. Three
sibling services set nothing and take the default of 1.

Picking a replacement by feel is the wrong move, because the failure is not
symmetric. Zero blanks the field, which is recoverable. A value that is too low
selects an upstream proxy's address and records it as the client's: with hops=1
against a two-entry header, idx = 2 - 1 = 1. A confident wrong IP in a
provenance record is what someone acts on during an incident.

The correct value is the number of proxies that appended on the way in, which
is a measurement rather than a preference. This logs that count alongside the
configured value, so one real request answers whether the deployment is right,
and logs the count only - never an address.

Also records why a pending docker status can mean the job will never run:
docker needs cargo, so a cargo failure leaves the status pending forever with
no task scheduled, which is indistinguishable from a queued job.

Refs #20

jlxq0 merged commit 873bb3cfed into main

2026-08-26 16:02:59 +00:00

jlxq0 deleted branch release-v0.2.1

2026-08-26 16:02:59 +00:00

jlxq0 referenced this pull request from a commit

2026-08-26 16:03:00 +00:00

Merge pull request 'chore(release): prepare v0.2.1' (#29) from release-v0.2.1 into main