Another issue: when continuing an existing conversation, the previous existing events are not included in the prompt to the LLM.

Of course! Also reported here and Vasco fixed it in the sdk already https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1783653808051339

thanks

We released agent-sdk (so agent-server) last night, I'm checking if we updated it in canvas

to fix, just need to pull the latest sdk version?

yes, but I think the sdk version is coded in canvas

I'm using git repos for all components

If you need a conversation right now, my agent did this - a single event edit - to relink the history: https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1783661863826019?thread_ts=1783653808.051339&cid=C06QT0AGY4W

The issue is still present in latest version of agent-server:

commit cf6c2a3a4ace65b651ea29032ab6b4a74d7bb41a (HEAD -> upstream, origin/main, origin/HEAD)
Author: Graham Neubig <neubig@gmail.com>
Date:   Sat Jul 11 13:05:37 2026 +0200

    [codex] fix ACP prompt argument order (#3996)

    Co-authored-by: Graham Neubig <gneubig@all-hands.dev>
    Co-authored-by: openhands <openhands@all-hands.dev>
    Co-authored-by: neubig <neubig@users.noreply.github.com>

Previous events are not sent to the LLM

Is this with the same conversation you tried before already, or a different conversation from the past, which you just restored on the new version?

I'm trying to fix existing conversations

I'm trying to say that maybe a conversation which you already restored before, got a

root

event

I will check

there's no need to revert

yes, it has:

"parent_id":"__root__"

I think Vasco's fix is not a migration, maybe we should also migrate affected conversations

definitively

You can work around for this particular conversation manually - or point your agent at enyst.github.io/arch/eventlog-resume-orphaned-history.html

must all events have a parent_id?

@bland-bear-604 refresh your knowledge by looking at the link I just gave, Vasco's recent PR on it, and open a PR with a one-time migration for this case: so I think one event somewhere at the tail of a conversation got

__root__

and it shouldn't, it should be linked to the previous non-system event But first answer Christopher's latest question please.

Short answer: no, not every event needs a

parent_id

, and the fix isn't to strip them all — it's to fix the one event that has the wrong value. How the walk works (

event_store.py::_effective_parent_id

): to rebuild context the agent walks child→parent from the newest event. For each event: •

parent_id == "__root__"

→ hard stop (this is the reserved

ROOT_PARENT_ID

sentinel — "I am a root, walk ends here") •

parent_id

set to a real id → follow it (new tree events) • no

parent_id

at all → fall back to the previous file (idx-1). This is the legacy back-compat path, so old flat-log events with no field load fine, unbranched. So your orphaning isn't caused by missing parent_ids — it's caused by one event at the tail (the first one written after you resumed across the 1.29.3→1.33.x boundary) getting stamped

parent_id: "__root__"

. That sentinel cuts the walk off from all the older events, even though they're all still on disk. To answer directly: • "Must all events have a parent_id?" — No. Legacy events without it are correct; leave them alone. • "Can we just remove the parent_id?" — Only on that one offending event. If you clear

"__root__"

from it, it falls back to the previous file (idx-1) and the history reconnects; the precise fix is to re-link it to the id of the previous non-system event. Don't bulk-remove parent_ids from the whole log — that would break any genuine tree links. Worked trace + recovery steps here: https://enyst.github.io/arch/eventlog-resume-orphaned-history.html On the corrupted

meta.json

on every restart — that's a separate issue; I'll look at it too. And Engel's asked me to open a one-time migration PR for the

__root__

-at-the-tail case so this heals automatically instead of by hand. 🐾

Any idea about this? https://openhands-ai.slack.com/archives/C06P5NCGSFP/p1783767185271159

No idea

yes

could you please make an issue on github?

ok

So for the migration, I would suggest to point your agent to the page with the explanation and workaround and let it fix that "root" - if you use an LLM you can trust to backup and not make a mess

Yes, but I'm facing 3 issues

I think that means the next time you reloaded them, the server rebuilds them cleanly, which sounds great

yep

Use the latest release of agent-canvas; and it brings with it a compatible/latest agent-server and automation packages

ok, so the best is to check the pyproject versions

we also have an issue open if you’d like to check it out - thinking over how to make an auto-upgrade or super smooth

have you considered keeping a stable branch?

I mean these releases:

I think it's good to have at least two versions

hotfixes = the patch version, that is, the 1.2.0 -> 1.2.1 , this latest patch release is precisely for the history issue

like Fedora vs Redhat

Yes

is this documented?

In various places... sort of. But it’s nothing special, it’s semver. That’s how it should work

ok

The best IMHO is the agent skill, because we are trying to automate as much as possible of course 😅 https://github.com/OpenHands/software-agent-sdk/blob/main/.agents/skills/sdk-release/SKILL.md#phase-1-trigger-the-prepare-release-workflow And if you want, you can see there about “version bumps” downstream, so the repos like agent-canvas get PRs created automatically, to update agent-sdk. Then at their turn, they use this release workflow:

Follow-up: opened the one-time migration PR → https://github.com/OpenHands/software-agent-sdk/pull/4090 Once it lands, affected conversations self-heal on resume — no more hand-editing the event file. Tested end to end (real session → damage → resume → history reconnected). Draft for now, will mark ready after review. 🐾