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

bug(pi): after resuming an interrupted conversation, gentle-engram 0.2.0 keeps the ended host session; POST /sessions is rejected with session_already_ended (Pi 1.0.1)

Open
  • Is something wrong?
#1,635 2 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
62/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
api, backend

Research direction

Start from the resume-registration path introduced in PR #1581 (register with resume semantics and adopt the continuation session id), then compare it with how the plugin reaches POST /sessions after a resumed Pi conversation; the rejected payload either omits the resume flag or reuses the ended host id. Check the server-side rejection returning session_already_ended, and inspect the mem_doctor check suite, which should flag a host session bound to an ended record. Done when writes succeed after resume or an explicit actionable error surfaces, and mem_doctor reports the blocked state.

Written by the indexing model from the issue text.

Description

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

After a long Pi conversation was interrupted and then continued (same conversation, same Pi session), every Pi-native memory write failed with session has already ended for the rest of the conversation.

This is related to #1622 (same stack family, same symptom) but adds one difference: on this path the plugin does reach POST /sessions. The TUI repeatedly showed the rejection as a warning, so the registration is attempted and rejected, not skipped. The plugin never adopts a continuation session and never surfaces the failure on the tool calls themselves beyond the generic error.

🔄 Steps to Reproduce
  1. Start a Pi conversation on Pi 1.0.1 + gentle-pi 4.0.0 + gentle-engram 0.2.0 + Engram 3.0.0. mem_save works normally.
  2. The conversation is interrupted (host session ends) and is then continued in place (same conversation and session id; PI_SESSION_ID / PI_SESSION_FILE are set in the resumed process).
  3. Call mem_save or mem_session_summary, either directly or from codemode.
  4. Every write fails with Error: session has already ended, and the TUI prints Warning: [engram] background capture to /sessions failed: session has already ended.
✅ Expected Behavior

As in PR #1581, a resumed session should register with resume semantics and adopt the core-acknowledged continuation session, or surface an explicit, actionable registration failure. Memory writes should work after resume without reopening the terminal session record.

❌ Actual Behavior
  • Every Pi-native write fails: mem_save and mem_session_summary, both as direct tool calls and from codemode.
  • The TUI repeatedly prints:
    Warning: [engram] background capture to /sessions failed: session has already ended
  • mem_session_start with a fresh explicit id returns {"status":"created"}, but the next mem_save still fails with the same error. Writes stay bound to the ended host session.
  • mem_doctor reports status: ok with 9/9 checks ok while writes are blocked, so the doctor does not detect a host session bound to an ended record.
  • Reads keep working (mem_stats, mem_current_project, mem_doctor).
Operating System

Linux (Arch/Manjaro)

Engram Version

3.0.0 (gentle-engram 0.2.0; gentle-pi 4.0.0; Pi 1.0.1)

Agent / Client

Other

📋 Relevant Logs
$ engram version
engram 3.0.0
$ pi --version
1.0.1

# TUI, repeated after the conversation was continued
Warning: [engram] background capture to /sessions failed: session has already ended

# mem_save / mem_session_summary (direct and via codemode)
Error: session has already ended

# mem_session_start with a new explicit id
{"id":"<new-id>","status":"created"}
# ...followed by mem_save
Error: session has already ended

# mem_doctor while writes are blocked
"status": "ok", "summary": {"total": 9, "ok": 9, "warnings": 0, "blocked": 0, "errors": 0}

# environment (presence only)
PI_SESSION_ID=set  PI_SESSION_FILE=set
PI_CODING_AGENT_DIR=unset  GENTLE_SHELL_RESUME_HANDOFF=unset
ENGRAM_URL / ENGRAM_PORT / ENGRAM_SOCKET / ENGRAM_BIN / ENGRAM_PROJECT = unset (defaults)
💡 Additional Context
  • Related: #1622 (Pi resume not re-registered on the same stack), #1376 (earlier Pi resume fix), #1593 (Codex sibling), #1624 (Claude sibling).
  • Difference from #1622: there, no registration mutation appeared after resume. Here, the /sessions call is visibly attempted and rejected with session_already_ended, which suggests the resume flag is not sent on this path, or the ended host id is reused instead of requesting a continuation.
  • Suggested hardening: mem_doctor could flag "current host session is ended" as a blocking check, since today it reports healthy while every write fails.
  • Workaround: restart the Pi session to get a fresh host session. No data was lost; the project task file lives in git.
  • I can capture the affected sessions row and the sync_mutations sequence (with consistently anonymized identifiers) if useful.
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.