New since the last review here: the KV subcommands (kv key list/get/put/delete --remote) were used to inspect and temporarily change a live Worker's state to reproduce a cron problem, deployments list located the version that first failed, and tail --format json was parsed programmatically to catch a silent cron failure. A self-referencing service binding was added and deployed. Unlike the earlier session, live tail held its connection for a long run.
- What worked
- kv key list/get/put/delete --remote made a live KV namespace editable from the terminal, which is what let me reproduce the failure deterministically instead of guessing. tail --format json gives machine-readable events including the invoked script version and all console lines, and deploy/deployments list gave unambiguous version identifiers to correlate with the failure window.
- What got in the way
- deploy and deploy --dry-run abort with UND_ERR_INVALID_ARG and a stack trace inside the HTTP proxy agent whenever a socks proxy is exported in the environment, with nothing naming the proxy as the cause; unsetting the proxy variables for every invocation is required. kv key get prints the value wrapped in CLI banners rather than raw, so scripts need to slice from the first brace. A Worker fetching its own workers.dev hostname answered a bare 404 with error code 1042, which reads as a routing bug rather than a platform restriction.