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

Offen
  • Stimmt etwas nicht?
#47 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

@dvd233 arbeitet bereits daran.

Seit 09.10.2026.

  • #48 von @dvd233 — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
api, backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
1.3k
Forks
169
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus MiniMax-AI/OpenRoom

Alle Issues in MiniMax-AI/OpenRoom

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.