ChronoModel does not work on Rails edge

[tagliala]

ChronoModel does not work on Rails edge.

The failures are visible in the Rails edge jobs from PR #413:
#413

Failing jobs:

• Ruby specs (3.3, rails_edge, 16, experimental)
• Ruby specs (3.4, rails_edge, 16, experimental)
• Ruby specs (head, rails_edge, 16, experimental)

[tagliala]

Bisect result:

• First bad Rails commit: 6901769a7e7332ca44bc9c05a26dd8431a9b890b (Introduce QueryIntent)
• Rails PR: Introduce Parameter Object: QueryIntent rails/rails#55897
• Rails commit: rails/rails@6901769

The failure is reproducible locally against the Rails checkout at ~/dev/rails. The focused DDL and counter-cache specs fail with PG::NotNullViolation because the temporal view trigger receives NULL for omitted/defaulted columns.

[tagliala]

The fix branch also adds Ruby 4.0 against Rails edge to the experimental CI matrix. All Rails edge experimental jobs now use PostgreSQL 18.

[tagliala]

PR #415 was updated with the remaining Rails edge compatibility fix. The full Rails edge suite now passes locally with PostgreSQL 18: 509 examples, 0 failures. The CI matrix now includes Ruby 4.0 + Rails edge on PostgreSQL 18.

[tagliala]

Best fix: PR #419, with PR #421 as the test follow-up (MAI Code 1.1)

My judgment is that the best production fix is PR #419.

The root issue is in adapter.rb: Rails edge no longer consistently funnels bulk schema metadata through column_definitions; it reads columns, primary_keys, and indexes directly, often with an array of table names. That bypasses the ChronoModel override that switches to the temporal schema, so the public view metadata is used instead of the temporal table metadata.

Why PR #419 is the strongest fix

• It fixes the actual root cause, not a side effect.
• It handles both single-table and array-of-table lookups, which is exactly what Rails edge does.
• It preserves mixed temporal/plain/history behavior and keeps schema-cache/dumper flows working.
• It keeps the adapter logic narrow and explicit: temporal tables are resolved through the temporal schema, everything else stays as-is.
• The regression specs in base_spec.rb are aligned with the real failure mode.

Why I would not pick the others as the main fix

• PR Fix Rails edge compatibility (GPT 5.6 Luna) #415: useful follow-up, but it only repairs the symptom around view defaults / edge error propagation; it does not address the bulk reader bypass.
• PR Fix Rails edge schema metadata lookups (GPT 6 Astra) #417: better than Fix Rails edge compatibility (GPT 5.6 Luna) #415, but it still feels more like a schema-routing workaround and is less directly aligned with the actual Rails API contract than Fix schema readers on Rails edge (Fable 5.1) #419.
• PR Fix Rails edge compatibility (GPT 5.6 Sol) #418: not as clean; it adds a separate columns adaptation and looks more workaround-heavy than the direct adapter override in 419.
• PR Fix Rails edge compatibility (GPT 5.4) #420: improves stale schema-path handling, but that is not the primary root cause; it is a secondary correctness fix.
• PR Fix Rails edge compatibility (Kimi K3) #421: good spec hygiene, especially replacing a Rails version check with feature detection, but it is not the production fix itself.

Recommended combination

If you want the final, robust patch set:

1. Merge the actual fix from PR Fix schema readers on Rails edge (Fable 5.1) #419
2. Merge the spec improvement from PR Fix Rails edge compatibility (Kimi K3) #421

That pair is the most correct and least brittle.

Verification

I checked the current repo baseline with:
bundle exec rspec spec/chrono_model/adapter/base_spec.rb

Result:

• 11 examples
• 0 failures

So the current adapter spec passes, and PR #419 is the fix that best matches the Rails-edge contract behind the bug.

[tagliala]

Recommendation: PR #420 (GPT 5.4) (Big Pickle)

Why it's the best:

1. Most surgical DDL fix — Reads columns(current) (the temporal table directly) instead of columns(table) (the VIEW). This is the most obvious and immediately understandable fix. Also caches temporal_columns to avoid calling columns twice (PR Fix Rails edge compatibility (GPT 5.6 Luna) #415 doesn't do this).
2. Cleanest on_schema fix — Simply removes the Thread.current['recursions'] == 1 guard from the transaction-abort condition. Previously, at inner recursion levels, the code tried self.schema_search_path = old_path which raised PG::InFailedSqlTransaction (replacing the original error). Now it always nils @schema_search_path on abort, which:

• Avoids the SET that fails on aborted transactions
• Ensures a fresh read from the server on next access
• Lets the original error propagate cleanly (no more exception replacement)

3. Minimal diff — +7/-5 total. No new modules, no method renames, no feature guards.
4. Test correctness — Changes the error regex to match the original error (syntax error at or near "ERRORING") rather than the replacement error (current transaction is aborted). This is correct across all Rails/PG versions since the ensure block no longer raises.
5. No risky API changes — Unlike PRs Fix Rails edge schema metadata lookups (GPT 6 Astra) #417 and Fix schema readers on Rails edge (Fable 5.1) #419, it doesn't rename primary_key → primary_keys.
   Runner-up: PR Fix Rails edge compatibility (GPT 5.6 Luna) #415 — Same DDL fix but uses $ERROR_INFO (Perl English globals) for the on_schema fix, which is less idiomatic than Fix Rails edge compatibility (GPT 5.4) #420's one-line condition change.