WrenAI 0.13.3 fixes an upgrade path escape—and four quieter production traps

WrenAI 0.13.3 is a maintenance release, but its most consequential changes sit below the chat interface: safer project migration, bounded planner state, correct limits and values at connector boundaries, and more useful failure classification. The release notes list the version as published August 18.

Treat legacy-context migration as a security-sensitive operation

The sharpest fix closes a path-traversal flaw in Wren’s v1-to-v2 context upgrade. The migration previously joined a YAML object name directly onto directories such as models/, then created and wrote files without first proving that the resolved target remained inside the project. Wren’s own reproduction showed a name containing ../../ writing outside that directory. The patched upgrader validates targets during planning and again before mutation, and rejects malformed projects before any write or delete begins, according to PR #2649.

That makes 0.13.3 the sensible minimum before importing or upgrading context bundles that were not authored entirely inside your trust boundary. Back up the project, run the planning step first, and make a rejected traversal error a review event—not something to work around by renaming files blindly.

The release also changes resource and result behavior

Long-running Wren processes could retain one SessionContext for every distinct extracted manifest because get_session_context used an unbounded cache. Version 0.13.3 replaces it with a 32-entry least-recently-used cache. The maintainers explicitly call 32 an initial hard-bound policy rather than a number derived from production memory or hit-rate measurements, so operators should watch latency and memory after upgrade instead of assuming that one capacity fits every workload, as PR #2628 explains.

Spark queries with a limit previously materialized the full result through toPandas() and only then sliced the Arrow table on the client. The fix applies DataFrame.limit(n) before collection, producing a server-side CollectLimit; it also rejects negative, Boolean and non-integral limits rather than silently accepting problematic values, according to PR #2574. Teams using MCP’s default result limit should re-run their largest representative Spark queries and compare driver memory and execution plans.

PostgreSQL users should regression-test decimals. For unconstrained NUMERIC, the connector had substituted a scale of nine, which could round a value such as 1.123456789012345 or fail on wider decimals. The fix returns unconstrained numeric values through an exact-string path, while constrained NUMERIC(precision, scale) continues to use Arrow decimal types, according to PR #2655. Downstream consumers that assumed every numeric-looking result arrived as a decimal object may therefore need schema-aware parsing.

Finally, bare connector TimeoutError exceptions are now classified as database timeouts instead of the same generic user-error bucket used for bad SQL. The change covers query and dry-run paths at the Wren engine layer; the author notes that tests used a fake connector rather than a live timed-out database, in PR #2654. Alerting and retry policies should key on the new timeout classification, but validate it against each production connector before enabling automatic retries.

A practical rollout order

Upgrade a staging instance first; exercise a legacy-context plan, a high-cardinality manifest workload, a large Spark query with a small limit, unconstrained PostgreSQL numerics and an intentionally timed-out query. Those tests map directly to the corrected paths in the 0.13.3 release and are more informative than a conversational smoke test alone.