riverpod_devtools v1.1.0
riverpod_devtools 1.1.0
Reliability and lightness release: bounded serialization cost for large state, faster MCP tool calls, a snappier extension under event bursts, and setup failures that explain themselves instead of degrading silently.
-
Serialization is now bounded at the source.
serializeValuepreviously capped only recursion depth; a provider holding a hugeList/Map/Set(or an object with a very longtoString()) was fully re-serialized on every update, on both the DevTools and MCP paths. Collections now serialize only their first 100 elements — flagged withtruncated: trueand the truetotalItems— and the stored string form is capped at 4000 chars. Anything trimmed carries the existinglossy: truemarker, and MCP compact summaries report the true (pre-cap) collection size. Large-state apps can keep the observer enabled without paying an unbounded per-event cost. -
Dependency-JSON load failures are now visible everywhere. A broken
riverpod_dependencies.jsonused to degrade silently to "no dependencies":- The registry retains the parse error (
RiverpodDevToolsRegistry.loadError). get_dependency_graphreturns a dedicatededgesNotewith the actual parse error (distinct from "never loaded" and "name mismatch").- Events carry
dependenciesSource: 'load_error'plus the reason (dependenciesLoadError), and the DevTools extension's Dependencies section shows a "Dependency Data Failed to Load" panel with the error and the fix command — instead of the generic setup instructions. - The README / doc-comment setup snippet now logs the load failure reason instead of recommending an empty
catch (_) {}.
- The registry retains the parse error (
-
MCP: app discovery is cached (~5s). Tool calls that omit
portno longer re-ping all 10 ports (1s timeout each) on every call; a failed request to a cached port invalidates the cache so a restarted app on a new port is re-discovered automatically. OneHttpClientis used per scan instead of one per port.list_riverpod_appsalways scans fresh. -
MCP:
get_dependency_graphexplains an emptyedges— when no static dependency data is loaded (or none of the running providers match it by name), the response carries anedgesNotedescribing whyedgesis empty and how to fix it, instead of being indistinguishable from "no dependencies". The note survives the compact view. -
MCP: the server reports its real version in the initialize handshake (was hardcoded to
0.1.0);tool/release.shkeeps it in sync. -
Extension: smoother under event bursts. The event list is rebuilt in a single pass per event (previously a full copy plus a head insert), and the per-provider stats recompute is throttled to at most once per 250ms with a trailing pass so the final state after a burst is never stale.
-
Reliability fixes:
- The
ext.riverpod_devtools.commandservice extension is only marked registered after registration actually succeeds, so a transient failure no longer permanently disables DevTools Invalidate/Refresh for the rest of the isolate's life. - The
POST /commandsinvalid-body error message no longer contains a truncated placeholder ("value"?: }→"value"?: <primitive>}), so an AI reading it can self-correct against valid JSON.
- The
-
Examples build from a fresh clone — the generated
riverpod_dependencies.jsonis now committed for both example apps, soflutter runworks immediately and the dependency-graph demo is live out of the box. -
Docs: TROUBLESHOOTING.md gained an MCP section covering the real failure modes (app not found / port forwarding, first-launch compile timeout, empty graph edges,
ambiguous: true,supported: false, multi-app port selection); MCP.md links to it and notes the one-time ~10–20s first-launch compile of the MCP server.
Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/1.1.0