[Bug] Agent file_write and file_delete report success when storage requests fail

Abierto
  • ¿Algo no está bien?
#47 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@dvd233 ya está trabajando en esto.

Desde el 9/10/2026.

  • #48 de @dvd233 — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, backend

Línea de trabajo

Start by reading executeFileTool and diskStorage.putTextFilesByJSON / deleteFilesByPaths, then trace how storage results become the Agent tool outcome. Add regression tests for HTTP 500 and rejected requests while preserving success behavior and best-effort behavior for other storage callers. Done means both file tools return an error for those failures, still return success for HTTP 200, and do not automatically retry.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Describe the Bug

At main commit 02468154c4d99f8925916425bf444d672454fb3d, executeFileTool('file_write', ...) and executeFileTool('file_delete', ...) return success when the corresponding /api/session-data request returns HTTP 500 or rejects with a network error.

diskStorage.putTextFilesByJSON and deleteFilesByPaths do not check response.ok and swallow fetch rejections. The file-tool handlers therefore continue to their success result. ChatPanel adds that result to the next model request as the tool's outcome.

Steps to Reproduce

I exercised the unchanged exported executeFileTool through the real diskStorage implementation, replacing only fetch with synthetic responses. This is a Node-based module reproduction, not a browser or live-provider test.

For each of file_write and file_delete, use a synthetic path such as apps/diary/data/entries/test.json (and valid JSON content for the write), then test:

  • fetch resolves with HTTP 500: actual result is success
  • fetch rejects with Error('synthetic offline'): actual result is success
  • fetch resolves with HTTP 200: actual result is success, as expected

That gives four failure cases incorrectly reported as success and two passing controls. No real files or provider requests were used.

Expected Behavior

The Agent should receive an error result when storage returns a non-success HTTP status or the request fails. A network error does not prove that the server made no change, so this should not automatically retry the mutation.

Screenshots

No browser screenshots were captured for this module-level reproduction.

Environment

  • OS: Linux
  • Browser: not used for this reproduction
  • Node.js: v24.19.0
  • pnpm: not used for the original module probe

Additional Context

Proposed scope

Keep existing best-effort behavior for other storage callers. Let these two Agent tools opt into failure propagation, using the current error: ... result format. Preserve tool schemas, successful output, read/list behavior, paths, and batch scheduling. Concurrent batches can still partially complete; this is not an atomicity or rollback change.

I can contribute a small fix with real file-tool/storage-path regression tests. AI assistance was used for diagnosis and testing.

Lenguaje dominante
TypeScript
Estrellas
1.3k
Forks
169
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MiniMax-AI/OpenRoom

Todos los issues de MiniMax-AI/OpenRoom

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.