test(integration-tests): add RTAS cases by mkuchenbecker · Pull Request #744 · linkedin/openhouse

mkuchenbecker · 2026-09-18T00:43:45Z

Stack context

These four same-repository draft PRs form the complete path from main
through RTAS. Each PR is based on the head branch of the preceding PR.

Order	Capability	Pull request
1	Integration test core	#741
2	Coverage documentation	#742
3	Standard DML	#743
4	RTAS	#744

main -> #741 ->
#742 ->
#743 ->
#744

Summary

This PR adds Replace Table As Select (RTAS) prepared tables and test cases on top
of the Standard DML layer. It adds 264 cases to the 130-case Standard DML
catalog, producing 394 combined cases.

This branch also fills the RTAS section in TEST-COVERAGE.md. The other
capability sections remain owned by their respective PRs.

Scope

This layer owns everything a CREATE OR REPLACE TABLE AS SELECT statement can
change about a table and everything the catalog governs about a table that
reached its state through a replace. It reuses every Standard DML operation as
data against replaced tables and excludes concurrency and locking, which belong
to the compatibility and streaming layer. ChangelogFixtures and
ConcurrencySupport live in this layer because RTAS is their first consumer.
TableMetadataFixtures provides the snapshot and catalog-name helpers shared
with later capability layers.

Family	Coverage	Cases
Reused Standard DML operations	Every applicable operation on four replace-lineage prepared tables, plus the null-string DELETE and two partition-scoped writes.	212
Replace contract	Enablement gates, same-shape replacement, schema discontinuities, partition replacement, property override and preservation, retention and tag preservation, time travel, rollback, changelog and incremental-read boundaries, rename ordering, sort order, identity preservation, and replace-versus-append behavior.	52
Total		264

Known limitations

Case	Reason	Skipped
`rtas.schema.incompatibleType.notSilentlyLossy` (Parquet, ORC)	A bigint-to-int replacement succeeds and wraps an out-of-range key instead of being rejected or preserving the value.	2
`rtas.concurrency.replaceVersusAppend` (Parquet, ORC)	A replace and an append can both report successful commits while the append's snapshot wins and loses the replace.	2

Every RTAS descendant inherits exactly these four skips; none of them adds a
new one.

Validation

Check	Result
`git diff --check` against the parent tip	Clean.
Added lines	ASCII only.
Embedded catalog	394 combined cases: 390 passed, 4 skipped, 0 failed.

Add 264 replacement-specific cases on the 642-case foundation. - run every reusable DML operation across four RTAS preparations - cover schema, partition, policy, history, rename, order, and identity - require precise lineage rejection and typed concurrency outcomes - expose silent narrowing corruption as a known product bug Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Keep the replace-versus-append assertion limited to serializable outcomes while recording the rare lost-replace result as a known bug. Both format cases remain available for re-enablement when concurrent RTAS commits report conflicts or preserve the replace. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>