merge: sync upstream main and web-studio file manager into new-frontend

[feichuans]

• Upstream: 68 PRs (Feature/memory opt volcengine/OpenViking#1159~feat(bot): Add disable OpenViking config for channels. volcengine/OpenViking#1352) covering CI, security, memory, session, storage
• web-studio: Viking File Manager with tree/list/preview, theme rework, sidebar refinement

[github-actions]

Failed to generate code suggestions for PR

[gemini-code-assist]

Code Review

This pull request replaces the Go-based AGFS with a Rust implementation (RAGFS), introducing native Python bindings and a new server architecture. It also enhances the vikingbot agent with improved memory retrieval, session management via a new /new command, and refined tool filtering. The LoCoMo benchmark suite and CLI tool received significant updates, including new search constraints and export capabilities. Feedback highlights several critical areas for improvement: hardcoded absolute paths in shell scripts, inefficient memory handling when reading large files, and dangerous recursive deletion logic for S3 root directories. Additionally, the reviewer noted performance bottlenecks caused by blocking I/O in async functions and sequential network requests, as well as potential race conditions in non-atomic database writes and insecure temporary file usage in the build process.

[gemini-code-assist]

The script contains a hardcoded absolute path /Users/bytedance/.openviking/data. This will cause the script to fail or delete incorrect data on any machine where the user is not bytedance. Use the $HOME environment variable instead.

Suggested change

	echo ""
	echo "Step 0b: Deleting data directory /Users/bytedance/.openviking/data..."
	if [ -d "/Users/bytedance/.openviking/data" ]; then
	rm -rf /Users/bytedance/.openviking/data
	echo " ✓ Deleted /Users/bytedance/.openviking/data"
	else
	echo " ✓ Data directory does not exist"
	fi
	echo ""
	echo "Step 0b: Deleting data directory $HOME/.openviking/data..."
	if [ -d "$HOME/.openviking/data" ]; then
	rm -rf "$HOME/.openviking/data"
	echo " ✓ Deleted $HOME/.openviking/data"
	else
	echo " ✓ Data directory does not exist"
	fi

[gemini-code-assist]

The current implementation reads the entire file into memory using fs::read before applying the offset and size constraints. This is extremely inefficient for large files and can lead to Out-Of-Memory (OOM) crashes. Additionally, fs::read is a blocking operation. It is recommended to use tokio::fs::File, seek to the offset, and read only the requested number of bytes.

[gemini-code-assist]

Executing remove_all on the root directory (/) will recursively delete all objects in the S3 bucket (or under the configured prefix). This is extremely dangerous and should be restricted or require an explicit confirmation/force flag to prevent accidental data loss.

[gemini-code-assist]

Writing to a fixed filename /tmp/extract_ragfs.py is insecure and can lead to race conditions if multiple builds run on the same machine. Since a unique temporary directory TMPDIR is already created, the script should be placed inside it. Note that you will also need to update the execution and removal lines (120-121) to use the new path.

		echo "import zipfile, glob, shutil, os, sys" > "$$TMPDIR/extract_ragfs.py"; \

[gemini-code-assist]

The std::io::copy operation is blocking and is being called within an async function. This can block the async runtime's worker threads. Consider using tokio::io::copy with a tokio::fs::File or wrapping the entire synchronous operation in tokio::task::spawn_blocking.

[gemini-code-assist]

Using std::fs::write in an async function blocks the executor thread. This can lead to performance degradation and thread starvation. Use tokio::fs::write instead.

Suggested change

	std::fs::write(&final_path, bytes)?;
	tokio::fs::write(&final_path, bytes).await?;

[gemini-code-assist]

The write operation uses a check-then-act pattern (path_exists followed by update_file or create_file) which is not atomic and prone to race conditions. It is better to use an UPSERT pattern (e.g., INSERT OR REPLACE or ON CONFLICT) in the database backend to ensure atomicity.

[gemini-code-assist]

The _parse_viking_memory function performs sequential await client.read_content calls for each memory entry. With the increased limit of 30 memories, this can significantly increase latency. It is recommended to fetch the contents in parallel using asyncio.gather before iterating to build the result string.

[gemini-code-assist]

The semaphore is instantiated inside the execute method, meaning it only limits concurrency within a single hook execution. If multiple requests trigger this hook simultaneously, the total number of concurrent commits to the server will not be restricted. Consider moving the semaphore to the class level or a shared configuration to effectively manage global concurrency.