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:
parent
93f4a3a7f7
commit
874b906b3d
@ -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 =
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user