Mathias Lafeldt

@ctsk Nice catch! #532 will fix this.

> Do u have `CLOUDFLARE_DEFAULT_ACCOUNT_ID` environment variable set by any chance? Nope. And setting it doesn't change things. Here's how to reproduce the problem: - Deploy the bucket using sst...

@fwang Any plans to fix this? Thanks.

I see. As a workaround, and since Pulumi v6 introduces many breaking changes anyway (`cloudflare.PagesProject`, `cloudflare.Record`, etc.), I deleted all stacks using sst 3.14 and redeployed them with sst 3.17.

I'm using the `chore/v0.6.0` branch.

Oh, I'm already trying to deserialize it as `Result`. Works fine for the `Ok` case, but the `FailedError` envelope gives me trouble in case of `Err`.

Yeah, you're probably right. It looks like the original error isn't serialized, so the inner error is just converted using to_string.

This works as documented here: https://duckdb.org/docs/stable/core_extensions/spatial/r-tree_indexes.html ``` ❯ cargo run --example repl Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s Running `target/debug/examples/repl` duckdb-rs v1.4.1 🦀 Type '.help' for help....

This is fixed now. ``` ❯ cargo run --example repl Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s Running `target/debug/examples/repl` duckdb-rs v1.4.0 🦀 Type '.help' for help. > install...

I added a test in #601 that shows each call to `Connection::open_in_memory` or `Connection::open_in_memory_with_flags` indeed creates an isolated in-memory database.