Repository navigation
watch: a stale cursor asks for twice as much; work: probes do not ask for a metadata service; msgpack 1.2.4 - #32
Merged
Merged
Conversation
…p to the server's ceiling The scanner asked every chat for at most WATCH_MAX_PER_CHAT (60) messages and, when a chat filled it, could only note that older ones may be missing: the results come newest first and the cursor moves to the newest. A second deployment running copies of these files hit that cap on two chats in each of two Monday first rounds — a weekend's backlog is not a round's. A chat whose cursor is older than 36 hours (after a weekend, a holiday, or a chat that just appeared) now asks for twice the limit, never more than 200, which is search_chat_records' own ceiling; weekday rounds are unchanged. The truncation note names the limit actually asked. Tested with a weekend group and a weekday group, at the default and at 150; the test fails with the fixed limit back.
…not exist on their network An AWS CLI call whose profile names no region asks 169.254.169.254 for one; on the probes that ask goes to the egress proxy, which refuses it, and every refusal lands in the egress ledger as an attempt to leave that nobody made. A second deployment running copies of these files saw six in one session for exactly this reason. The probes sit on an internal network and their AWS credentials are files, so AWS_EC2_METADATA_DISABLED=true joins the shared probe environment: the CLI says 'specify a region' instead, and the posture check skips the metadata question. The operator's current profile names its region, so nothing changes today; this keeps the next profile from writing false refusals.
CVE-2026-114613 (msgpack's C extension leaks a decoded value when a map key is rejected; fixed in 1.2.3) turned the gate red at pip-audit; every service's lock carried 1.2.1, main included. msgpack reaches the venvs only through pip-audit's own cachecontrol (msgpack>=0.5.2,<2.0.0), and the images install runtime packages only, so no published image carries it. 1.2.4 is the newest release, tagged upstream; installed into each venv, the locks regenerated by scripts/relock.sh, and msgpack is the only pin that moved. STACK GATE GREEN.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-ups from a second deployment running copies of these files, by Claude (claude-opus-5-5) at the repository owner's request.
1. A stale cursor asks for twice as much. The watch scanner asked every chat for at most
WATCH_MAX_PER_CHAT(60) messages, and a chat that filled it could only be noted as possibly missing older ones: results come newest first and the cursor moves to the newest. The other deployment hit the cap on two chats in each of two Monday first rounds. A chat whose cursor is older than 36 hours now asks for twice the limit, never more than 200, which issearch_chat_records' own ceiling; weekday rounds are unchanged. The test fails with the fixed limit back.2. The work stack's probes do not ask for an instance metadata service. An AWS CLI call whose profile names no region asks 169.254.169.254 for one; on the probes that goes to the egress proxy, which refuses it, and each refusal lands in the egress ledger as an attempt to leave that nobody made. The other deployment saw six in one session.
AWS_EC2_METADATA_DISABLED=truejoins the shared probe environment indeploy/docker-compose.work.yml(compose resolves it on all three probes). The operator's current profile names its region, so nothing changes today.3. msgpack 1.2.4 for CVE-2026-114613, which turned the gate red at pip-audit on this branch and is on main too. It reaches the venvs only through pip-audit's own cachecontrol; no published image carries it. Lock-only, own commit.
The third follow-up, guidance on the chat tools' targets and same-name matches, went into the planner's methodology on the work deployment's volume (
work-data/probe-plan/system-prompt.md), which is not tracked; the watch brief already tells the watcher not to call chat tools at all.Gate: STACK GATE GREEN locally; CI read back before merging. Nothing here is in a published image, so no release follows.