fix: merge accountId fallback from extractDeliveryInfo in update.run handler

When a caller forwards live channel/to via deliveryContext but omits
accountId (e.g. /tools/invoke without x-openclaw-account-id), the
update.run handler was using paramsDeliveryContext as-is, dropping any
account binding that existed in the session store. The restart sentinel
would then be written without accountId, causing scheduleRestartSentinelWake
to deliver using the channel default account — misrouting in multi-account
setups.

Apply the same accountId fallback pattern that config.ts already uses:
when paramsDeliveryContext is present but its accountId is undefined,
merge in extractedDeliveryContext.accountId as fallback. See #18612.
This commit is contained in:
Bryan Marty 2026-03-10 02:05:32 +00:00
parent 93f4a3a7f7
commit 874b906b3d
No known key found for this signature in database

View File

@ -28,7 +28,17 @@ export const updateHandlers: GatewayRequestHandlers = {
const { deliveryContext: extractedDeliveryContext, threadId: extractedThreadId } =
extractDeliveryInfo(sessionKey);
const paramsDeliveryContext = parseDeliveryContextFromParams(params);
const deliveryContext = paramsDeliveryContext ?? extractedDeliveryContext;
// When live channel/to is present but accountId is missing (e.g. /tools/invoke without
// x-openclaw-account-id), fall back to the session-extracted account so the sentinel is
// not written without account context — which would cause deliveries to use the channel
// default account and misroute in multi-account setups. See config.ts for the same pattern.
const deliveryContext =
paramsDeliveryContext != null
? {
...paramsDeliveryContext,
accountId: paramsDeliveryContext.accountId ?? extractedDeliveryContext?.accountId,
}
: extractedDeliveryContext;
const threadId = paramsDeliveryContext?.threadId ?? extractedThreadId;
const timeoutMsRaw = (params as { timeoutMs?: unknown }).timeoutMs;
const timeoutMs =