Skip to content

[Bug]: pSpool Abort can clear a live batch reused by another slot #25854

Description

@XuPeng-SH

Is there an existing issue for the same bug?

  • I have checked the existing issues.

Branch Name

main

Commit ID

1a14737

Other Environment Information

  • Hardware parameters: N/A; deterministic unit reproduction
  • OS type: Platform independent
  • Others: Pipeline spool with one or multiple local receivers

Actual Behavior

After a receiver releases a batch, pSpool returns the batch to its cache and the slot to its free pool but leaves the old slot metadata intact. Because the cache and slot pools reuse objects independently, that batch can next be owned by another slot while the old free slot still aliases it. Abort scans and cleans every non-current slot, so cleaning the stale slot clears the batch that a receiver is currently reading. The receiver observes an empty batch and data loss.

Expected Behavior

A slot must relinquish all data, error, cache, and reference metadata before it is published to the free pool. Abort must preserve every batch currently owned by a receiver until the final ReleaseCurrent call.

Steps to Reproduce

  1. Initialize a spool with one receiver.
  2. Send, receive, and release a batch so its batch object and slot are returned to their independent pools.
  3. Send and receive a second batch. The cache reuses the first batch object in the other slot.
  4. Call Abort before ReleaseCurrent.
  5. Observe that the current batch row count changes from 1024 to 0.

The same failure reproduces with a broadcast batch and two receivers.

Additional information

The stale metadata originates at the normal release boundary. Abort cleanup introduced in #25273 makes the stale alias observable, but adding an Abort-specific exception would not restore ownership correctness. The systemic fix is to detach metadata before returning either pooled object, with single-receiver, broadcast, late-release, cleanup, and race coverage.

Metadata

Metadata

Assignees

Labels

kind/bugSomething isn't workingseverity/s0Active / top priority for current sprint. Owner has committed to working on it now.

Type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions