Blender data changed but the interface did not

One-time reads versus subscriptions

state.get reads one snapshot without listening. Use subscriptions or stores for ongoing changes. Page variables do not automatically become Blender state.

Confirm the query includes the target data

1. Declare fields for custom state. Requested fields, filters, sorting, and limits must be supported.
2. Match item/list shape and read item or items. The get wrapper is not the snapshot.
3. Filters may exclude a target and limits may truncate lists. Inspect actual results before assuming a missing item means refresh failed.
4. Custom handlers implement filtering and sorting; generic validation does not perform business filtering.

For declarations and return examples, see State, queries, and refresh.

Notify rereads after data changes

Custom Python state needs invalidation after relevant changes. Actions can declare invalidates; other business code can call state.invalidate. Changes outside actions also need notifications through the add-on's change paths. The framework cannot infer arbitrary custom changes.

Invalidation recomputes but does not promise a different result every time. Identical data may reuse snapshots. Hidden pages need not display every intermediate value. Do not replace proper notifications with tight polling.

Check subscription ownership and page lifetime

Inspect errors, connection signals, and cleanup timing. The SDK attempts to restore active subscriptions after ordinary disconnects. stale/session_closed terminate the old document; do not wait indefinitely on old handles. Release old listeners on remount and late handles after unmount.

Stores may retain old values alongside error. Do not label items current without checking it. Prevent old snapshots from overwriting local drag previews. See Transform interactions.

Trace data through to display

• Change one value and confirm the Python state result changes accordingly.
• Confirm the current page receives a new snapshot and updates the correct control.
• Reopening or changing filters produces neither duplicate notifications nor stale content.

Events describe what happened; they are not a sufficient sole state source after reopening.