Skip to content
Engineering Insight
Awaiting weekly review
Memory was restored. Was pending work restored too?
Research

Memory was restored. Was pending work restored too?

A pinned source-derived class probe separates historical memory from pending inbox persistence. Available helpers do not establish checkpoint integration.

2026-11-03中文 →

Memory was restored. Was pending work restored too? ​

An object loads successfully and its history remains. That still leaves a separate question: what happened to messages delivered before a crash but not yet observed by their recipient? Our internal isolated probe retains observed memory while restoring an empty inbox. Its engineering value is to separate what a system knew from work it still owes, rather than to announce reproduction of a complete framework recovery defect.

The boundary between read history and an unread inbox ​

MetaGPT's role context declares its pending-message buffer excluded from serialization and supplies a default factory that creates a new queue. Serialization writes an object into saveable data; an excluded field is not retained by that model's ordinary export. The role source is public primary-source implementation evidence, not an independent recovery test.

The ordinary Team save/restore path examined in analysis contains no explicit call to the inbox dump/load helpers. That source observation is limited to the read path. It cannot exclude external storage, custom subclasses or other integrations.

Nor does a message remaining in environment history establish that the recipient regains pending work. Without verified replay, a durable copy somewhere and executable work restored to its owner are different propositions.

A bounded probe separates the two states ​

The analysis on 3 November 2026 extracted RoleContext, MessageQueue and RoleReactMode from pinned source, preserving their class ASTs unchanged. It used Pydantic 2.12.3 and explicit minimal stubs for Message, Memory, Action, BaseEnvironment and logging. This is a source-derived isolated class probe, not a full framework run.

Each control included one observed memory record and zero, one or three pending messages. The experiment compared a model dump/validate roundtrip with explicit queue dump/load.

Pending inputPending IDs restored by model roundtripObserved memoryPending IDs restored by explicit helpers
0EmptyRetainedEmpty
1EmptyRetainedOriginal one ID
3EmptyRetainedOriginal three IDs, in order

Source: the internal isolated-class output linked below. Nonempty controls show that this was not merely an already-empty queue. Retained observed memory also rules out a complete failure to restore anything as an explanation for this difference.

The serialized keys omit the pending buffer; reconstruction creates an empty queue through the default factory, consistent with the source declaration. Explicit helper success supports a bounded capability on a quiescent queue. It establishes neither an atomic concurrent snapshot nor durable storage or exactly-once external effects.

A helper, a promise and an integration are different evidence ​

The queue source supplies dump/load helpers: dumping reads message representations and reinserts original objects in a finally block; loading parses saved messages into a new queue. Message and queue source establishes availability. An excluded field, an available helper and a save entry point that actually invokes the helper must be examined separately.

For a specification comparison, Microsoft Agent Framework's checkpoint documentation includes pending messages and requests/responses in state. It also requires compatible topology and identities, custom-state hooks, and trusted storage and serialization boundaries. The official documentation describes another allocation of responsibility. It did not undergo an equivalent recovery test here.

One side is an isolated implementation observation with bounded execution; the other is a documented contract. They do not rank framework quality. Including pending state in documentation alone cannot establish crash consistency, restored authority or external-effect deduplication.

This is not a full product defect reproduction ​

The retained role, schema and Team source blob IDs begin 49b1d178, 52badcc2 and 5a983888; full identities are in the experiment data. These pin source blobs and bytes, not a complete repository commit. Our dependency versions are not a verified upstream lockfile environment.

The probe did not execute full Team or MGX paths, real Message/Memory serialization, custom restore hooks, a language model or crash cut points. The original issue describes loss between delivery and observation, but the admitted comments contain only an inactivity bot notice, without substantive maintainer confirmation. The issue remains unverified discussion. Our probe adds internal evidence at a specific model boundary only.

A resulting research check is to account separately for accepted, observed, executed and externally effective messages. A no-LLM fixture using actual Team and pinned complete dependencies should inspect IDs, order and recipients at delivery-to-observation cut points. Restored authority and effect deduplication need separate tests. This is a proposed verification design, not an established fix. The unresolved question is whether a complete deployment preserves and redelivers this work through another path.

Evidence and sources ​

Project source supplies public primary-source facts. Our bounded execution is internal experimental evidence, not independent validation. Official documentation supplies a specification promise, while an issue supplies a reported observation. Publication, citation and implementation success do not automatically establish general validity.

Last updated: