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

Ouverte
  • Quelque chose ne va pas ?
#47 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

@dvd233 y travaille déjà.

Depuis le 9/10/2026.

  • #48 par @dvd233 — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
76/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
api, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
1.3k
Forks
169
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MiniMax-AI/OpenRoom

Toutes les issues de MiniMax-AI/OpenRoom

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.