Fix/pipeline mid loop resume

[Aarkin7]

Related Issues

• fixes Resuming a pipeline snapshot after the first loop visit fails with PipelineComponentsBlockedError #12145

Proposed Changes:

Resuming a pipeline snapshot could fail when the breakpoint hit a component on its second visit (or later) in a loop. The root cause was that the snapshot lost the input provenance needed to know that the paused component should run again.

This PR preserves that provenance in new snapshots, keeps a best-effort compatibility path for older snapshots, and fixes the optional-socket sentinel case so resume does not silently drop paused inputs.

How did you test it?

• hatch run test:unit test/core/pipeline
• hatch run test:integration test/core/pipeline/breakpoints
• hatch run test:types
• hatch run fmt haystack/core/pipeline/breakpoint.py haystack/core/pipeline/pipeline.py test/core/pipeline/test_breakpoint.py
• Reproduced the original blocked-resume case and the optional-socket regression locally

Notes for the reviewer

• Suggested review order:

  1. haystack/core/pipeline/breakpoint.py
  2. haystack/core/pipeline/pipeline.py
  3. test/core/pipeline/test_breakpoint.py

• If you only look at one test first, please start with test_break_point_with_pipeline_snapshot_resumes_mid_loop_visit, because it captures the core failure this PR fixes.

• The main cases covered by tests are:

  • new-format mid-loop resume
  • legacy snapshot compatibility
  • one-shot legacy resume behavior
  • optional socket / _NO_OUTPUT_PRODUCED handling

• One intentional tradeoff: raw saved snapshot inputs are now more internal-looking because they preserve sender metadata needed for correct resume behavior.

• Legacy snapshots are supported on a best-effort basis; older files may still be limited by missing provenance in the original snapshot format.

Checklist

• I have read the contributors guidelines and the code of conduct.
• I have updated the related issue with new insights and changes.
• I have added unit tests and updated the docstrings.
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test: and added ! in case the PR includes breaking changes.
• I have documented my code.
• I have added a release note file, following the contributors guidelines.
• I have run pre-commit hooks and fixed any issue.

[vercel]

@Aarkin7 is attempting to deploy a commit to the deepset Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Hi @Aarkin7, thanks for your interest in contributing to Haystack! 🙏

⚠️ Issue #12145 is already being addressed by open pull request(s) #12152. Before opening a PR for an issue, please check whether a PR is already linked to it, and consider contributing to the existing PR instead. We may close duplicate PRs to keep the review queue manageable.

⚠️ You currently have 3 open pull requests in this repository (#11963, #11814 and this one). Our review capacity is limited, so please hold off opening more PRs until we've had a chance to review your first 2 open PRs. This helps us give each contribution the attention it deserves. Thank you!

This is an automated message to help us keep the review queue healthy.