Problem
A database handle (from any of Perry's four migrated drivers — pg, mysql2, ioredis, mongodb) is process-global, while the underlying turnloop connection it now refers to is thread-local. A handle created on the main agent and then used from a perry/thread worker now rejects, where the previous sqlx/redis/mongodb-crate-backed connections would have worked (those libraries' connections were reachable across the shared tokio runtime regardless of which OS thread called them).
Status, as reported by the lane that found it
This is explicitly a consequence of the (unmerged) turnloop migration itself, not a pre-existing defect — quoting the report that found it: "This is a consequence of the migration rather than a pre-existing defect; it applies to all four bindings and wants one tracker covering them." It is filed here as a single tracker covering all four bindings, per that recommendation, since it is a Perry-side architectural mismatch (process-global handle registry vs. thread-local transport) rather than a gap in the turnloop crates themselves.
Why it matters
Any Perry program that creates a database client on one agent and passes its handle into a spawn/parallelMap closure — a normal perry/thread usage pattern — will find that handle silently stops working once the underlying transport is turnloop-based, for all four database bindings at once.
What would fix it
Options range from making the turnloop connection reachable across the threads that share a handle's process-global identity, to making the handle itself agent-scoped (matching where its connection actually lives) and giving a clear error when it's used from the wrong agent, to a per-agent connection-migration mechanism. The shape is open; the lane that found it recommended it be tracked as one issue across all four bindings rather than four duplicates, since a single design decision applies to all of them.
Problem
A database handle (from any of Perry's four migrated drivers —
pg,mysql2,ioredis,mongodb) is process-global, while the underlying turnloop connection it now refers to is thread-local. A handle created on the main agent and then used from aperry/threadworker now rejects, where the previoussqlx/redis/mongodb-crate-backed connections would have worked (those libraries' connections were reachable across the shared tokio runtime regardless of which OS thread called them).Status, as reported by the lane that found it
This is explicitly a consequence of the (unmerged) turnloop migration itself, not a pre-existing defect — quoting the report that found it: "This is a consequence of the migration rather than a pre-existing defect; it applies to all four bindings and wants one tracker covering them." It is filed here as a single tracker covering all four bindings, per that recommendation, since it is a Perry-side architectural mismatch (process-global handle registry vs. thread-local transport) rather than a gap in the
turnloopcrates themselves.Why it matters
Any Perry program that creates a database client on one agent and passes its handle into a
spawn/parallelMapclosure — a normalperry/threadusage pattern — will find that handle silently stops working once the underlying transport is turnloop-based, for all four database bindings at once.What would fix it
Options range from making the turnloop connection reachable across the threads that share a handle's process-global identity, to making the handle itself agent-scoped (matching where its connection actually lives) and giving a clear error when it's used from the wrong agent, to a per-agent connection-migration mechanism. The shape is open; the lane that found it recommended it be tracked as one issue across all four bindings rather than four duplicates, since a single design decision applies to all of them.