increase WS client thread stack to 16KB #14
Merged
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
Despite the title ("increase WS client thread stack to 16KB"), this PR bundles many large, unrelated changes: a new XiaoZhi WSS channel, a new A2A protocol server/client, an HTTP transport for the MCP server, a shared URL parser refactor used across several channels, an agent_mem mallinfo guard, a Python skill security scanner, new Kconfig options, and the actual WS client stack bump.
Changes:
- Add
infra/url_parse.{c,h}and refactormcp_client,tool_fetch_url,feishu_http,weixin_channel,cmd_llmto use it. - Add
infra/a2a_handler.{c,h}(HTTP server + client) and route incoming HTTP throughws_serverto A2A and a newmcp_server_try_handle_httpHTTP/JSON-RPC transport. - Add XiaoZhi channel (WS + Opus + UDP transport), Kconfig switch, NSH
set_xiaozhicommand, agent_main wiring, and bumpAGENT_WS_CLIENT_STACKfrom 12 KB to 16 KB.
Reviewed changes
Copilot reviewed 28 out of 28 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| include/agent_config.h | Bump WS client stack to 16 KB; add XiaoZhi config keys |
| src/infra/url_parse.{c,h} | New shared URL parser for http/https/ws/wss |
| src/infra/a2a_handler.{c,h} | New A2A protocol server (well-known card, invoke, health) and client |
| src/tools/mcp_server.{c,h} | Add HTTP/JSON-RPC transport mcp_server_try_handle_http |
| src/tools/mcp_client.c | Switch to shared url_parse |
| src/tools/tool_fetch_url.c | Switch URL parsing to url_parse; redundant TLS gate |
| src/channels/ws_server.c | Peek HTTP and dispatch to A2A / MCP HTTP / WS handshake |
| src/channels/xiaozhi_*.{c,h} | New XiaoZhi WSS channel + Opus codec wrapper + UDP transport |
| src/channels/weixin_channel.c | Use url_parse for baseurl host extraction |
| src/channels/feishu_http.c | Use url_parse for WS URL parsing |
| src/channels/cmd_llm.c | Use url_parse for backend URL parsing |
| src/channels/nsh_commands.c | Add set_xiaozhi CLI command |
| src/agent_main.c | Init/start/stop XiaoZhi channel; comment cleanup |
| src/core/agent_loop.c | Reduce a stack buffer from 4096 to 2048 bytes |
| src/core/agent_mem.h | Guard mallinfo() with !CONFIG_DEBUG_MM and provide defaults |
| Kconfig | Add AI_AGENT_BLE_GATT, AI_AGENT_BLE_NET, AI_AGENT_XIAOZHI |
| CMakeLists.txt | Wire up new sources |
| scripts/skill_security_scan.py | New Python skill security scanner |
| agent_skills/autoresearch.md | New skill markdown |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| /* ── WS client thread stack ──────────────────────────────────── */ | ||
| #define AGENT_WS_CLIENT_STACK (12 * 1024) | ||
| #define AGENT_WS_CLIENT_STACK (16 * 1024) |
Comment on lines
+263
to
+307
| int wait_rc = sem_timedwait(&ctx->sem, &ts); | ||
|
|
||
| /* Mark done so late tap callbacks are no-ops */ | ||
| ctx->done = true; | ||
| mbus_tap_unregister(tap_key); | ||
|
|
||
| if (wait_rc != 0 || !ctx->response) { | ||
| free(ctx->response); | ||
| sem_destroy(&ctx->sem); | ||
| free(ctx); | ||
| http_respond(fd, 504, "Gateway Timeout", "application/json", | ||
| "{\"error\":\"agent timeout\"}"); | ||
| return; | ||
| } | ||
|
|
||
| /* Build A2A response with Message format */ | ||
| cJSON *resp = cJSON_CreateObject(); | ||
| if (!resp) { | ||
| free(ctx->response); | ||
| sem_destroy(&ctx->sem); | ||
| free(ctx); | ||
| http_respond(fd, 500, "Internal Server Error", "application/json", | ||
| "{\"error\":\"OOM\"}"); | ||
| return; | ||
| } | ||
| cJSON_AddStringToObject(resp, "status", "completed"); | ||
| cJSON *out_msg = cJSON_AddObjectToObject(resp, "message"); | ||
| if (out_msg) { | ||
| cJSON_AddStringToObject(out_msg, "role", "agent"); | ||
| cJSON *parts = cJSON_AddArrayToObject(out_msg, "parts"); | ||
| if (parts) { | ||
| cJSON *part = cJSON_CreateObject(); | ||
| if (part) { | ||
| cJSON_AddStringToObject(part, "type", "text"); | ||
| cJSON_AddStringToObject(part, "text", ctx->response); | ||
| cJSON_AddItemToArray(parts, part); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| char *json = cJSON_PrintUnformatted(resp); | ||
| cJSON_Delete(resp); | ||
| free(ctx->response); | ||
| sem_destroy(&ctx->sem); | ||
| free(ctx); |
Comment on lines
+652
to
+653
| if (!pe || (pe - buf - 5) != 4 || strncmp(buf + 5, "/mcp", 4) != 0) | ||
| return false; |
Comment on lines
+509
to
+528
| char *json = cJSON_PrintUnformatted(resp); | ||
| cJSON_Delete(resp); | ||
| if (json) { http_respond(fd, 200, "OK", json); free(json); } | ||
| } | ||
|
|
||
| static void http_jsonrpc_error(int fd, cJSON *id, int code, const char *msg) | ||
| { | ||
| cJSON *resp = cJSON_CreateObject(); | ||
| if (!resp) return; | ||
| cJSON_AddStringToObject(resp, "jsonrpc", "2.0"); | ||
| cJSON_AddItemToObject(resp, "id", id ? cJSON_Duplicate(id, 1) | ||
| : cJSON_CreateNull()); | ||
| cJSON *err = cJSON_AddObjectToObject(resp, "error"); | ||
| if (err) { | ||
| cJSON_AddNumberToObject(err, "code", code); | ||
| cJSON_AddStringToObject(err, "message", msg); | ||
| } | ||
| char *json = cJSON_PrintUnformatted(resp); | ||
| cJSON_Delete(resp); | ||
| if (json) { http_respond(fd, 200, "OK", json); free(json); } |
Comment on lines
+522
to
+537
| /* Generate a stable MAC-like ID from node ID hash */ | ||
| uint8_t hash[6]; | ||
| const char* nid = CONFIG_EXAMPLES_AI_AGENT_VELA_NODE_ID; | ||
| size_t nid_len = strlen(nid); | ||
| if (nid_len == 0) { | ||
| nid = "agent-01"; | ||
| nid_len = strlen(nid); | ||
| } | ||
| for (int i = 0; i < 6; i++) { | ||
| hash[i] = (uint8_t)(nid[i % nid_len] ^ (i * 37)); | ||
| } | ||
| hash[0] |= 0x02; /* locally administered bit */ | ||
| snprintf(s_device_id, sizeof(s_device_id), | ||
| "%02X:%02X:%02X:%02X:%02X:%02X", | ||
| hash[0], hash[1], hash[2], hash[3], hash[4], hash[5]); | ||
| syslog(LOG_INFO, "[%s] generated device_id: %s\n", TAG, s_device_id); |
| if (strncmp(url, "https://", 8) != 0) { | ||
| /* Parse URL */ | ||
| parsed_url_t pu; | ||
| if (url_parse(url, &pu) != 0 || !pu.use_tls |
MCP HTTP handler adds body[4096] on stack inside client_thread, pushing total stack usage to 100% of the 12KB allocation. This causes Data Abort (DFAR=0x99) when curl sends MCP initialize. Increase AGENT_WS_CLIENT_STACK from 12KB to 16KB. RAM impact: +4KB. Signed-off-by: zhouwenjie1 <zhouwenjie1@xiaomi.com>
skyxiaobai
force-pushed
the
sync-7-ws-stack
branch
from
13c850a to
d2bcf64
Compare
TangMeng12
approved these changes
May 14, 2026
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.
Note: Please adhere to Contributing Guidelines.
Summary
Update this section with information on why change is necessary,
what it exactly does and how, if new feature shows up, provide
references (dependencies, similar problems and solutions), etc.
Impact
Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.
Testing
Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.