On main at f30f550, extractText in internal/sessions/exec_session.go:271 walks the payload with for _, item := range typed over a map[string]any. Go randomizes map iteration, so the same session renders its resume context with fields in a different order on every process.
Observed while writing the tool-context tests for #1016: a tool_call line came out as c1 read_file {"path":...} on one run and {"path":...} c1 read_file on the next. The tests there compare fields as a set to work around it.
Why it matters: the block that says "Previous session context" is part of the user prompt, so the same session produces a different prompt each resume. That defeats any provider-side prefix caching for that block and makes prompts non-reproducible when debugging a resume, since two runs of one session do not diff cleanly.
Fix is small: sort the keys before iterating, in the map[string]any case only. The summary short-circuit above it is unaffected. Worth a test that asserts a fixed order for a known payload; a same-process repeat can pass by luck, so the assertion should be on the exact rendered line rather than on two runs agreeing.
Not introduced by #1016; it is on main today and that PR only made it visible.
On
mainat f30f550,extractTextininternal/sessions/exec_session.go:271walks the payload withfor _, item := range typedover amap[string]any. Go randomizes map iteration, so the same session renders its resume context with fields in a different order on every process.Observed while writing the tool-context tests for #1016: a
tool_callline came out asc1 read_file {"path":...}on one run and{"path":...} c1 read_fileon the next. The tests there compare fields as a set to work around it.Why it matters: the block that says "Previous session context" is part of the user prompt, so the same session produces a different prompt each resume. That defeats any provider-side prefix caching for that block and makes prompts non-reproducible when debugging a resume, since two runs of one session do not diff cleanly.
Fix is small: sort the keys before iterating, in the
map[string]anycase only. Thesummaryshort-circuit above it is unaffected. Worth a test that asserts a fixed order for a known payload; a same-process repeat can pass by luck, so the assertion should be on the exact rendered line rather than on two runs agreeing.Not introduced by #1016; it is on main today and that PR only made it visible.