The warning branch added in the previous commit was committed with an
always-false guard (`if (false && skippedCount > 0 && ...)`), so the
notification never fired — flagged by review as [P1]. Remove the
`false &&` so partial-album media loss actually notifies the user, as
the accompanying tests already expect.
Refs #55216
Telegram albums where some photos failed to download were processed
silently: the agent received only the photos that resolved, and the
user was never told images had been lost.
processMediaGroup now tracks a skippedCount (incremented on a
recoverable per-photo fetch error and on a null resolveMedia result).
When at least one photo still resolved, it emits a single anchored
warning per album (never per photo) using the same
withTelegramApiErrorLogging wrapper + swallowed-send pattern as the
existing single-attachment "Failed to download media" notice. The
all-failed-album case is intentionally left silent (out of scope).
Fixes#55216
* fix(browser): derive Chrome launch readiness from a single CDP diagnostic (#82904)
The pre-fix launch path used `isChromeReachable` (a lightweight HTTP
`/json/version` probe) to decide failure, then called the stronger
`diagnoseChromeCdp` only to format the thrown error. On macOS cold
starts where the HTTP probe transiently fails *between* the polling
loop and the diagnostic call, the runtime would throw
"Failed to start Chrome CDP on port ... { ok: true, wsUrl: ... }"
— a self-contradicting error containing a successful diagnostic
result. Per #82904 this is the actual user-visible bug.
Capture `diagnoseChromeCdp` ONCE after the polling loop and use it for
both the decision and the error text. The diagnostic helper already
includes the lightweight reachability check and adds a websocket
`Browser.getVersion` health command, so it is strictly stronger than
the HTTP probe; if `diagnoseChromeCdp` returns ok the launch
genuinely succeeded.
The existing `withMockChromeCdpServer` success test in
chrome.internal.test.ts still exercises this code path end-to-end
(real HTTP server + real websocket handshake), so the regression-safety
case is covered. The asymmetric `probe-fails-but-diagnostic-succeeds`
scenario is hard to mock without restructuring the existing test
harness; this commit ships the fix and relies on the upstream
ClawSweeper review criteria (manual managed-Chrome cold-start proof)
plus the standalone real-behavior probe in the PR body.
* fix(browser): import ChromeCdpDiagnostic type from chrome.diagnostics
The annotation `let finalDiagnostic: ChromeCdpDiagnostic | null` referenced
a type that was only re-exported (not imported) inside chrome.ts, causing
oxlint/tsc to read it as the implicit `error` type and fail check-lint,
check-prod-types, check-test-types, etc. Add the type to the existing
chrome.diagnostics.js import block.
* fix(browser): preserve Chrome launch diagnostic fallback
* test(browser): satisfy launch diagnostic lint
* fix(browser): keep Chrome launch readiness scoped
* test(browser): answer CDP launch mock probe
---------
Co-authored-by: hclsys <hclsys@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Route Together video generation through the v2 video API even when shared Together text config points at the v1 base URL.
Verification:
- pnpm test extensions/together/video-generation-provider.test.ts
- pnpm check:test-types
- git diff --check
- codex-review --parallel-tests "pnpm test extensions/together/video-generation-provider.test.ts"
- gh pr checks 82992 --watch --fail-fast=false
Avoid installing Codex native PostToolUse/Stop hook relays when OpenClaw has no matching local handlers. This keeps pre-tool safety and permission approval relays active while removing idle no-op subprocess fan-out.
Fixes#76552.
Co-authored-by: evgyur <evgyur@users.noreply.github.com>
