Clean up duroxide-pg migration follow-ups

docs/dep_issues.md

@@ -2,7 +2,7 @@
 
 **Purpose:** Track duroxide-pg issues/limitations that require workarounds in pg_durable.
 
-**Last Updated:** 2026-01-06
+**Last Updated:** 2026-05-26
 
 **GitHub Query:** [All pg_durable issues in duroxide-pg](https://github.com/microsoft/duroxide-pg/issues?q=is%3Aissue+label%3Apg_durable)
 
@@ -44,21 +44,23 @@ _No active blockers at this time._
 
 | Field | Value |
 |-------|-------|
-| **Issue** | [microsoft/duroxide-pg#6](https://github.com/microsoft/duroxide-pg/issues/6) |
+| **Issue** | `microsoft/duroxide-pg-opt#6` (historical, private repo) |
 | **Also filed** | [microsoft/duroxide-pg#1](https://github.com/microsoft/duroxide-pg/issues/1) (FYI only) |
 | **Status** | ✅ Resolved |
-| **Fixed In** | duroxide-pg v0.1.9 (requires duroxide 0.1.11) |
+| **Fixed In** | duroxide-pg-opt v0.1.9 (requires duroxide 0.1.11) |
 
 **Resolution Date:** 2026-01-06
 
 **Problem (was):**
-When upgrading `duroxide` or `duroxide-pg` versions, the PostgreSQL schema in the `duroxide` schema may change (new columns, changed function signatures, etc.). This caused runtime errors:
+When upgrading `duroxide` or `duroxide-pg-opt` versions, the PostgreSQL schema in the `duroxide` schema may change (new columns, changed function signatures, etc.). This caused runtime errors:
 - `function duroxide.XXX does not exist` (function signature changed)
 - `column index out of bounds` (table columns changed)
 - `cached plan must not change result type` (prepared statement cache invalidated)
 
 **Resolution:**
-The duroxide-pg v0.1.9 release includes ProviderAdmin lifecycle management which handles schema versioning. No workarounds were needed in pg_durable codebase at the time of the fix.
+The duroxide-pg-opt v0.1.9 release includes ProviderAdmin lifecycle management which handles schema versioning. No workarounds were needed in pg_durable codebase at the time of the fix.
+
+_Note: this blocker was tracked against the private `duroxide-pg-opt` provider. Since v0.2.2, pg_durable depends on the crates.io `duroxide-pg` crate instead; the historical issue link is preserved as a plain reference because the private repo is not publicly accessible._
 
 ---
 
@@ -81,6 +83,6 @@ When updating the duroxide dependency, run through this checklist:
 ## Version Compatibility Matrix
 
 | pg_durable | duroxide | duroxide-pg | Notes |
-|------------|----------|-----------------|-------|
-| 0.1.1 | 0.1.11 | 0.1.9 | Current - schema versioning fix |
-| 0.1.0 | 0.1.6 | 0.1.6 | Legacy |
+|------------|----------|-------------|-------|
+| 0.2.2 | 0.1.29 | 0.1.34 (crates.io) | Current — switch from private `duroxide-pg-opt` to crates.io `duroxide-pg`; starts a new provider compatibility line (see [docs/upgrade-testing.md](upgrade-testing.md)) |
+| ≤0.2.1 | 0.1.x | `duroxide-pg-opt` 0.1.x (private) | Legacy provider line; Azure fork owns its upgrade testing |

docs/extension_lifecycle.md

@@ -1,7 +1,7 @@
 # pg_durable Extension Lifecycle and Background Worker
 
 **Status:** Implemented  
-**Last Updated:** 2026-03-01  
+**Last Updated:** 2026-05-26  
 **Dependencies:** duroxide-pg (crates.io)
 
 > **Note:** This document describes the extension lifecycle management, background worker behavior, and duroxide-pg schema integration in pg_durable.

docs/upgrade-testing.md

@@ -172,10 +172,10 @@ Each PR that changes the extension schema or modifies SQL queries in Rust code s
 2. Bump `Cargo.toml` version to `<N+1>`
 3. If this release starts a new provider compatibility line, update the `PROVIDER_COMPAT_START_VERSION` default in `scripts/test-upgrade.sh` and document the boundary under "Version-Specific Changes". Downstream forks can instead override `PROVIDER_COMPAT_START_VERSION` in CI to keep the script shared.
 
-If this is the first minor after a new major (e.g. 1.0.0 → 1.1.0), also:
+If this is the first minor after a new major (e.g. 1.0.0 → 1.1.0), additionally:
 
-4. Check in `sql/pg_durable--<major>.sql` as the first install SQL fixture for the new major (e.g. copy the generated `pg_durable--1.0.0.sql` from the extension directory)
-5. Optionally delete the previous major's install SQL fixture and upgrade scripts — they are no longer needed by any of A, B1, or B2
+- Check in `sql/pg_durable--<major>.sql` as the first install SQL fixture for the new major (e.g. copy the generated `pg_durable--1.0.0.sql` from the extension directory)
+- Optionally delete the previous major's install SQL fixture and upgrade scripts — they are no longer needed by any of A, B1, or B2
 
 No additional fixture is needed for subsequent minors — intermediate versions are reconstructed by chaining `ALTER EXTENSION UPDATE` from the first version's install SQL.
 

src/lib.rs

@@ -827,7 +827,7 @@ mod tests {
 
     /// Wait for a durable function to complete, polling Duroxide status
     fn wait_for_completion(instance_id: &str, timeout_secs: u64) -> Result<String, String> {
-        use crate::types::{new_backend_provider, postgres_connection_string, DUROXIDE_SCHEMA};
+        use crate::types::{new_backend_provider, postgres_connection_string};
         use duroxide::Client;
         use std::time::{Duration, Instant};
 
@@ -884,7 +884,7 @@ mod tests {
 
     /// Get the current status from Duroxide
     fn get_duroxide_status(instance_id: &str) -> Option<String> {
-        use crate::types::{new_backend_provider, postgres_connection_string, DUROXIDE_SCHEMA};
+        use crate::types::{new_backend_provider, postgres_connection_string};
         use duroxide::Client;
 
         let _ = ensure_store_ready().ok()?;