mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-13 19:23:42 +08:00
349f4d7d3c
The two tools-sync scripts ran on every startup and used H2 MERGE INTO ... KEY(id), which overwrites every column on existing rows. That silently reverted UI-toggled `enabled` and was the proximate cause of a recent WriteFileTool/EditFileTool outage. They were also a strict subset of the fresh-install seed (data-zh.sql / data-en.sql register all 19 builtins; the sync scripts only 16) and out of date. Per-tool Flyway migrations (V3, V31) are already the canonical 'register a new builtin' path, so the sync layer was duplicated and error-prone. Delete both files and the runToolSyncScript() loader. Tool descriptions shown to the LLM come from @Tool annotations in code, not the DB row, so removing per-startup metadata refresh has no functional impact.
64 lines
2.7 KiB
Java
64 lines
2.7 KiB
Java
package vip.mate.config;
|
|
|
|
import lombok.RequiredArgsConstructor;
|
|
import org.springframework.boot.autoconfigure.condition.ConditionalOnWebApplication;
|
|
import org.springframework.context.annotation.Bean;
|
|
import org.springframework.context.annotation.Configuration;
|
|
import org.springframework.web.socket.config.annotation.EnableWebSocket;
|
|
import org.springframework.web.socket.config.annotation.WebSocketConfigurer;
|
|
import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry;
|
|
import org.springframework.web.socket.server.standard.ServletServerContainerFactoryBean;
|
|
import vip.mate.channel.web.TalkModeWebSocketHandler;
|
|
|
|
/**
|
|
* WebSocket 配置
|
|
* <p>
|
|
* 注册 Talk Mode WebSocket 端点。
|
|
*
|
|
* @author MateClaw Team
|
|
*/
|
|
@Configuration
|
|
@EnableWebSocket
|
|
@RequiredArgsConstructor
|
|
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET)
|
|
public class WebSocketConfig implements WebSocketConfigurer {
|
|
|
|
/**
|
|
* Max binary frame the TalkMode WebSocket accepts. Recordings come over
|
|
* as 16 kHz / 16-bit / mono PCM WAV — roughly 32 KB per second of audio.
|
|
* 8 MB headroom covers ~4 minutes of speech, which is more than any
|
|
* realistic single-turn voice message. Default is 8 KB which used to
|
|
* crash the connection (CloseStatus 1009 "Message too big") on every
|
|
* non-trivial recording.
|
|
*/
|
|
private static final int MAX_BINARY_BUFFER_BYTES = 8 * 1024 * 1024;
|
|
|
|
/** Text frames stay reasonably small (init / state / transcript JSON). */
|
|
private static final int MAX_TEXT_BUFFER_BYTES = 64 * 1024;
|
|
|
|
private final TalkModeWebSocketHandler talkModeHandler;
|
|
|
|
@Override
|
|
public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
|
|
registry.addHandler(talkModeHandler, "/api/v1/talk/ws")
|
|
.setAllowedOrigins("*");
|
|
}
|
|
|
|
/**
|
|
* Tomcat-level buffer override. Without this Spring's
|
|
* {@link org.springframework.web.socket.handler.AbstractWebSocketHandler}
|
|
* still buffers the whole binary message before dispatching to the handler
|
|
* — capped at 8 KB by default — and a single voice clip blows past that
|
|
* limit on the very first send. Bumping the binary buffer is simpler than
|
|
* implementing partial-message handling, given the bounded size of
|
|
* speech-to-text clips. See discussion in the V46 STT bug-fix series.
|
|
*/
|
|
@Bean
|
|
public ServletServerContainerFactoryBean createWebSocketContainer() {
|
|
ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean();
|
|
container.setMaxBinaryMessageBufferSize(MAX_BINARY_BUFFER_BYTES);
|
|
container.setMaxTextMessageBufferSize(MAX_TEXT_BUFFER_BYTES);
|
|
return container;
|
|
}
|
|
}
|