Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

bug(pi): resume after quit is not re-registered on gentle-engram 0.2.0 / Engram 3.0.0 (Pi 1.0), memory writes fail with session_already_ended

Open
  • Is something wrong?
#1,622 14 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go, sqlite, typescript
Domain
backend

Research direction

Start from the PR #1581 resume-registration path and the core resume registration added in PR #1564, then locate the Pi-side resume/session hook in the gentle-engram package that should send resume: true. Check whether it fires for resumes that bypass pi --continue/pi --resume (session picker, launcher hint) and where adoption-acknowledgement errors are swallowed instead of surfaced; the mutation log in the issue (no session upsert after ended_at) is the reference for done: a new registration/ack mutation appears on resume and mem_save succeeds afterward. No pull request exists yet, so confirm current claim status in the 10-comment thread first.

Written by the indexing model from the issue text.

Description

priority:high status:needs-review type:bug
📝 Bug Description

On the new resume protocol (gentle-engram 0.2.0 + Engram core 3.0.0, PR #1581 / #1564), a Pi session that is quit and later resumed is not re-registered: no new session row and no adopted acknowledgement appear, and every memory write fails closed with session has already ended for the rest of the conversation.

This looks like a coverage gap of the #1376 fix on Pi 1.0: the resume registration either never fires on this resume path or fails silently, because there is no rejection evidence either (no 409, no surfaced error).

Runtime facts: Pi 1.0.0 runtime via gentle-pi 4.0.0 (isolated agent home), gentle-engram 0.2.0 (npm), engram binary 3.0.0 (brew). Both components were installed before the session booted, so the whole session ran on this stack - no mid-session upgrade confound.

🔄 Steps to Reproduce
  1. Start a Pi conversation on gentle-engram 0.2.0 + engram 3.0.0. mem_save works (observation 1022 saved, sync mutation seq 9085 at 2026-10-02 03:51:10 UTC).
  2. Quit the Pi TUI. The session-end hook fires and the sessions row gets ended_at (sync mutation seq 9086, session upsert at 03:52:27 UTC).
  3. Resume the same conversation afterwards: same session id, same session file, conversation continues (the exact resume invocation was not captured; Pi session picker or a launcher resume hint).
  4. Any mem_save, mem_update or mem_capture_passive now fails with session has already ended, for the rest of the conversation.
✅ Expected Behavior

Per PR #1581, a resumed session should register with resume: true and adopt the core's validated acknowledgement as its effective session (or surface an explicit registration failure). Memory writes should work after resume without reopening the terminal session record.

❌ Actual Behavior
  • No new session row of any kind is created on resume: no adopted continuation, no client-side generated row. The runtime keeps binding writes to the original, already-ended session id.
  • Every Pi-native memory write is refused with session has already ended (mem_save, mem_update, mem_capture_passive).
  • mem_session_start with an explicit id creates an independent shared session, but Pi-native writes still bind to the current host session, so they keep failing. mem_session_end refuses an explicit non-host id ("Pi-native session end requires the current host session ID").
  • The engram save CLI bypasses the host-session binding and works, so nothing is lost; only the Pi-native path stays blocked until the next fresh boot.
Operating System

Linux (Ubuntu/Debian)

Engram Version

3.0.0 (engram binary via brew; gentle-engram 0.2.0; Pi runtime 1.0.0 via gentle-pi 4.0.0)

Agent / Client

Other

📋 Relevant Logs
$ engram version
engram 3.0.0

-- sessions row for the affected session (UTC timestamps; identifiers kept for correlation)
id             = 01a0faa8-4d9d-756a-ba5a-c1ef4df69c4f
project        = <project-name>
directory      = /home/<user>/.../<project-name>
started_at     = 2026-10-02 03:32:13.328385656
ended_at       = 2026-10-02 03:52:27            <- user quit here
ownership_mode = project_owned

-- sync_mutations around the transition
seq   entity       op      source  occurred_at           note
9084  prompt       upsert  local   2026-10-02 03:32:13   boot prompt capture
9085  observation  upsert  local   2026-10-02 03:51:10   mem_save still works (obs 1022)
9086  session      upsert  local   2026-10-02 03:52:27   end hook sets ended_at
-- no session registration mutation exists after 03:52:27

-- every later Pi-native write (mem_save, mem_update, mem_capture_passive):
Error: session has already ended
💡 Additional Context
  • Same failure family as #1376 (closed, fixed by PR #1581 using the core resume registration from #1564) and the open Codex sibling #1593. This occurrence is on the fixed stack (gentle-engram 0.2.0 + core 3.0.0), so the resume registration appears to be skipped or silently failing on this path, not rejected with 409.
  • Suspects worth checking: whether the Pi resume hook fires for resumes that do not go through pi --continue / pi --resume (e.g. the session picker or a launcher resume hint), and whether an adoption-acknowledgement failure is swallowed instead of surfaced.
  • Workaround that worked: engram save CLI with explicit --project. The orphaned shared session created by mem_session_start was deleted afterwards.
Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
11h 17m
Merged PRs (30d)
334

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.