From bb40d9217b77f31fc5a2bbc8c8543db8e47d7bff Mon Sep 17 00:00:00 2001 From: Eric Andrechek Date: Sun, 4 Oct 2026 00:05:18 -0400 Subject: [PATCH] docs: the per-call settings validation gap is fixed in the current artifact build The artifact producer's build 20261004.021416, which every tag now resolves to, refuses an invalid per-call setting value with the server's own code and refuses a filter created with an invalid session_timezone (36). The first 1.0 build stays fetchable by digest or through a lock, so the entry keeps its workaround for that build and says how to move to the current one. Co-Authored-By: Claude Opus 5.5 (1M context) Claude-Session: https://claude.ai/code/session_012NdkF6p8Q3qkdxKCgbdjgb --- docs/limitations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/limitations.md b/docs/limitations.md index 7e3b991d..12d7e7eb 100644 --- a/docs/limitations.md +++ b/docs/limitations.md @@ -195,9 +195,9 @@ When the filter evaluates in a different time zone than the batch it runs over, ### Per-call settings values are not validated the way a server's `SET` validates them -Some invalid values for a per-call setting are accepted, where a server's `SET` would refuse them. +**Fixed in the artifacts, build `20261004.021416` and later** (no SDK change). The artifact producer reports that an invalid value for a per-call setting is now refused with the server's own error code, as a server's `SET` refuses it, and that a filter created with an invalid `session_timezone` is refused at create (code 36). Every tag and line resolves to that build by default. -**Workaround:** validate settings values in the caller, or against a server, before relying on a refusal here. **Planned.** +On the first 1.0 build, `20261003.231921`, which stays fetchable by digest and through a lock that pins it, some invalid values are still accepted. **Workaround on that build:** validate settings values in the caller, or against a server, before relying on a refusal here, or move to the current build: `chtypes fetch ` resolves it, and a locked project re-resolves with `chtypes fetch --lock --update`. ### `lossy` on a String holding a raw NUL in TSV