chat/rollback with null contentId truncates history at the first idless message

Offen
#669 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
clojure, json
Bereich
api, backend

Rechercherichtung

Start with rollback-chat in src/eca/features/chat.clj and trace how it handles the supplied contentId; the report identifies null matching the first idless message. Check the compaction marker and summary creation in src/eca/shared.clj, then reproduce with the synthetic history fixture and JSON-RPC request described here. Done means a missing, null, or unknown target is rejected before history or files change, with regression coverage for the reported rollback cases.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Describe the bug

Measured with ECA 0.167.0 over JSON-RPC: chat/rollback accepts contentId: null and discards history starting at the first message without a content ID. A seven-message fixture with ordinary idless assistant text retained only the first user message, including after server restart.

With include: ["messages", "tools"] and rollback records present, the same request also reverted file changes after that point. This was measured with synthetic records, not live edit-tool calls. Normal persistence strips those records, so this does not establish file reversal after a server restart; that risk concerns records still held in a live session.

To Reproduce

Use a disposable workspace and cache; this request destroys history.

  1. Prepare a chat containing an ID-bearing user message, an idless assistant answer, an idless compaction marker/summary, and subsequent turns. A synthetic stored-history fixture suffices; no model request is needed.
  2. Send:
    {"jsonrpc":"2.0","id":1,"method":"chat/rollback","params":{"chatId":"<fixture-chat>","contentId":null,"include":["messages"]}}
    
  3. Read chat/history, restart the isolated server, and reopen the chat.
  4. Only the first user message remains. The request returned {} rather than an error.

Measured UI trigger on eca-emacs master b353d444dca3e1f54c6c724a20eda372ee5443d7: render the isolated server's history containing a seeded compaction summary, expand the summary, and activate its rollback action with RET. The client still offers rollback without a message ID. Its actual request params were:

{"chatId":"<fixture-chat>","contentId":null,"include":["messages"]}

Choosing messages and tool changes instead emitted "include":["messages","tools"], also with a null target. Forwarding each captured request unchanged to ECA 0.167.0 retained only the first user message, including after restart. This used batch Emacs and a source-shaped seeded summary, not live /compact or a GUI mouse click.

Expected behavior

Reject a missing, null, or unknown rollback target before changing history or files. Clients should not offer rollback on blocks without a valid target ID.

Doctor

eca --version: eca 0.167.0; macOS, headless stdio client. No provider or model was involved. /doctor was not collected.

Additional context

Source-inferred cause, still present at ECA master 065e77319960b96ee96f7d86d86d4d0cd95257a1:

  • rollback-chat uses take-while / drop-while comparing each message's :content-id to the supplied ID, without validating the target first. Null therefore matches the first idless message, not the selected summary.
  • Compaction appends a marker and user-role summary without IDs.
  • eca-emacs user-text rendering offers rollback without a nil-ID guard.

Related: eca-emacs #136, “Rollback chat to before this message stays after compact.” That report concerns the available action; these results establish the destructive server behavior of a null target.

Vorherrschende Sprache
Clojure
Sterne
1k
Forks
82
Ø Merge
1 T. 21 Std.
Gemergte PRs (30 T.)
25

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

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 editor-code-assistant/eca

Alle Issues in editor-code-assistant/eca

Ähnliche Issues

Weitere Issues zu Clojure

Neue Issues direkt in Ihr Postfach

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