Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cached UC managed Delta table reads remain stale after RTAS or overwrite on Spark 4.0.1

Aperta
  • Qualcosa non va?
#59,627 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
scala
Ambito
backend, databases

Direzione di ricerca

Start by reading Spark 4.0.1's DataSourceV2Strategy and the cached-plan invalidation path, then compare the qualified-name invalidation change in PR #52599. Reproduce the RTAS and saveAsTable overwrite cases with the supplied Spark, Delta, and UC versions, checking whether cache invalidation matches the cached V1 LogicalRelation. Done means fresh reads return replacement rows and the dependent cached view is refreshed, with the append control still fresh.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

We observed stale cached query results after successful replacement of a UC managed Delta table on Spark 4.0.1 with Delta 4.2.0 and OSS Unity Catalog 0.6.0. Both SQL REPLACE TABLE AS SELECT and DataFrameWriter.saveAsTable(mode="overwrite") are affected. The writes and reads occur in the same Spark session; this is not an external writer requiring explicit refresh.

Reproduction workflow

Precondition: a configured UC catalog supporting managed Delta tables, Java 17, and the matching Spark-line Delta/UC artifacts. Use independent tables for the two variants.

  1. Create a UC managed Delta table containing (1, 'original'), with delta.feature.catalogManaged=supported, deletion vectors disabled and CDF disabled.
  2. Cache the qualified table name and materialize its rows. For the RTAS variant, also cache and materialize a dependent temporary view.
  3. Replace the table with (2, 'replacement'), (3, 'replacement') through RTAS, or overwrite the independently seeded table with (3, 'overwritten') through saveAsTable.
  4. Read the qualified table name through a newly created query, without REFRESH TABLE, CLEAR CACHE or manual uncache.

Expected: the new query returns the replacement rows; the dependent cached view also reflects the replacement.

Actual on Spark 4.0.1: Delta history advances to version 1, but the fresh query still returns (1, 'original'). The dependent view in the RTAS variant is stale too. No persisted-data loss has been observed.

Verification
Spark Delta Execution RTAS saveAsTable overwrite Append control
4.0.1 4.2.0 local[4] Stale Stale Fresh
4.0.1 4.2.0 Standalone, separate driver/executor JVMs Stale Stale Fresh
4.1.1 4.2.0 local[4] Fresh Fresh Fresh

The Spark-line comparison uses the corresponding Delta and UC artifacts, not byte-identical dependencies.

Diagnosis and question

The cached analyzed plan contains a V1 LogicalRelation. Spark 4.0.1's DataSourceV2Strategy constructs a synthetic DataSourceV2Relation for invalidation; it does not match the cached plan (sameResult == false, cache lookup empty). Both writes execute AtomicReplaceTableAsSelectExec. Repeating relation-based uncache after recording the stale read leaves the cache intact; qualified-name uncache clears it and the next read returns the committed replacement rows.

PR #52599, whose stated purpose is TimeTravelSpec support, also changes this strategy to qualified-name invalidation. We reference that code change as a possible explanation for the passing Spark 4.1.1 control, not as confirmation that this specific defect was reported or fixed there. We have not tested an isolated backport. Please confirm ownership of the V1/V2 invalidation mismatch and whether a focused correction for Spark 4.0.x is appropriate.

Lingua principale
Scala
Stelle
44.2k
Fork
29.5k
Merge medio
8h 43m
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/spark

Tutte le issue di apache/spark

Issue simili

Altre issue su Scala

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.