chore!: Remove legacy pipeline_outputs deserialization support

[GunaPalanivel]

Description

Removes the temporary backward-compatibility layer for deserializing legacy pipeline_outputs format in pipeline snapshots. This cleanup was scheduled for Haystack 2.23.0 as documented in issue #10168, following the fix introduced in PR #10096.

Breaking Change Details

What Changed

Before (backward compatible):

# Supported both old and new formats
if "serialization_schema" not in pipeline_snapshot.pipeline_state.pipeline_outputs.keys():
    pipeline_outputs = pipeline_snapshot.pipeline_state.pipeline_outputs  # Old format
else:
    pipeline_outputs = _deserialize_value_with_schema(...)  # New format

After (new format only):

# Only supports new serialization schema format
pipeline_outputs = _deserialize_value_with_schema(pipeline_snapshot.pipeline_state.pipeline_outputs)

Impact

• ❌ Old format (pre-v2.17.0): {"comp1": {"result": "value"}} - No longer supported
• ✅ New format (v2.17.0+): {"serialization_schema": {...}, "serialized_data": {...}} - Required

Who Is Affected?

Users with pipeline snapshots created before Haystack 2.17.0 (November 2025) that use pipeline breakpoints.

Migration Path

Option 1: Recreate Snapshots (Recommended)

# Simply re-run your pipeline with breakpoints using Haystack 2.17.0+
pipeline.run(data=input_data, include_outputs_from={"component_name"})
# New snapshots will automatically use the correct format

Option 2: Manual Migration
If you have critical old snapshots, manually convert the pipeline_outputs field:

Old format:

{
  "pipeline_state": {
    "pipeline_outputs": {
      "component1": {"output_key": "output_value"}
    }
  }
}

New format:

{
  "pipeline_state": {
    "pipeline_outputs": {
      "serialization_schema": {
        "type": "object",
        "properties": {
          "component1": {
            "type": "object",
            "properties": {
              "output_key": {"type": "string"}
            }
          }
        }
      },
      "serialized_data": {
        "component1": {"output_key": "output_value"}
      }
    }
  }
}

Changes Made

Code Cleanup

• haystack/core/pipeline/pipeline.py (lines 252-259)

  • Removed 5 lines of conditional deserialization logic
  • Simplified to single _deserialize_value_with_schema() call

• test/core/pipeline/test_breakpoint.py (lines 157-185)

  • Removed test_load_pipeline_snapshot_with_old_pipeline_outputs_format() test (31 lines)
  • This test verified backward compatibility which is no longer needed

Documentation

• releasenotes/notes/remove-legacy-pipeline-outputs-deserialization-5acccb0245b84890.yaml
  • Added breaking change release note
  • Documented migration instructions
  • Explained impact and timeline

Related Issues

• Closes Remove support for deserialization of old pipeline_outputs from pipeline snapshot #10168 (Remove support for old pipeline_outputs deserialization)
• Ref fix: serialization of pipeline_outputs in pipeline snapshot #10096 (Original PR that fixed serialization and added temporary backward compatibility)
• Part of milestone 2.23.0

Testing

Tests Passing ✅

# All breakpoint tests pass after removal
$ hatch run test:unit test/core/pipeline/test_breakpoint.py -v
========================================== 13 passed in 2.45s ===========================================

# Related pipeline snapshot tests pass
$ hatch run test:unit test/core/pipeline/test_pipeline_crash_regular_pipeline_snapshot_is_raised.py -v
========================================== 3 passed in 1.12s ============================================

# Code formatting passes
$ hatch run test:format
All checks passed!

Verification Steps

1. ✅ Removed backward compatibility code doesn't break existing tests
2. ✅ New snapshots still serialize/deserialize correctly
3. ✅ Pipeline state handling remains consistent
4. ✅ No regressions in breakpoint functionality

Timeline and Context

Date	Event
Nov 18, 2025	PR #10096 introduced new format + backward compatibility
Dec 1, 2025	PR #10096 merged to main
Dec 1, 2025	Issue #10168 created to track removal
Dec 15, 2025	This PR removes backward compatibility for v2.23.0

Rationale: Two-week grace period allowed users to upgrade and migrate snapshots before breaking change.

Checklist

• Removed conditional deserialization logic from pipeline.py
• Removed backward compatibility test from test_breakpoint.py
• Created breaking change release note with clear migration path
• All existing tests pass (13 breakpoint tests, 3 crash handling tests)
• Code formatted and linted (hatch run test:format)
• Used conventional commit format with ! for breaking change
• Documented impact, timeline, and migration options
• Verified no regressions in pipeline snapshot functionality

Notes for Reviewers

Why This Is Safe to Remove

1. ✅ Time Buffer: 2 weeks since new format was introduced (merged Dec 1)
2. ✅ Clear Deprecation: Marked with TODO: remove this in haystack 2.23.0
3. ✅ Milestone Alignment: Scheduled removal for 2.23.0 release
4. ✅ Limited Scope: Only affects users with old snapshots (pre-Nov 2025)

What to Review

• Breaking change documentation is clear and actionable
• Migration instructions are complete
• Release note follows Haystack conventions
• No unintended side effects from removal

---

Related Documentation:

• Pipeline Breakpoints Guide
• Serialization Schema Docs

Release Note File Content

# releasenotes/notes/remove-legacy-pipeline-outputs-deserialization-5acccb0245b84890.yaml
---
upgrade:
  - |
    **Breaking Change**: Removed backward compatibility support for legacy ``pipeline_outputs`` 
    format in pipeline snapshots.
    
    Pipeline snapshots created before Haystack 2.17.0 (November 2025) will no longer deserialize 
    correctly. The new format requires ``serialization_schema`` and ``serialized_data`` fields.
    
    **Migration Required:**
    
    - **Option 1 (Recommended)**: Re-run pipelines with breakpoints using Haystack 2.17.0+ to 
      generate new snapshots with the correct format.
    
    - **Option 2**: Manually convert old snapshots by wrapping ``pipeline_outputs`` content in 
      the new serialization schema structure (see PR #10168 for format details).
    
    **Timeline**: The legacy format was deprecated in PR #10096 (merged December 1, 2025) with 
    a two-week migration period before removal in version 2.23.0.

[vercel]

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

A member of the Team first needs to authorize it.

[anakin87]

Blocking this PR for now, as the change is planned for release in 2.23.0 and we still need to complete the 2.22.0 release first.

[GunaPalanivel]

Hi @anakin87,

Thank you for the review! I completely understand the release timing - makes perfect sense to complete the 2.22.0 release before merging changes planned for 2.23.0.

Questions:

1. Should I keep this PR open and ready, or would you prefer I close it and reopen after 2.22.0 ships?
2. Are there any code changes needed, or is this purely a timing hold?
3. Is there anything I should update while we wait for the 2.22.0 release?

I'll keep an eye on this PR and respond quickly to any feedback once you're ready to move forward.

Thanks for coordinating the release process so carefully!

Best regards,
Guna

[anakin87]

I'd say you can leave it open and we can resume it when it's 2.23.0 (in early 2026).

[GunaPalanivel]

Hi @anakin87,

Hope you're doing well! I wanted to follow up on this PR now that we're in the 2.23.0 milestone period.

I noticed the PR currently has merge conflicts that need to be resolved. I'm happy to:

• Rebase the branch against the latest main
• Fix any merge conflicts
• Run the test suite again to ensure everything still passes
• Address any additional feedback you might have

Before I proceed with the rebase, I wanted to check:

1. Is this still on track for the 2.23.0 release?
2. Are there any other changes or improvements you'd like me to make to the PR?
3. Would you prefer I resolve the conflicts now, or should I wait for any additional review feedback first?

I've kept the branch ready and I'm available to make any adjustments quickly to help move this forward.

Thanks for your patience and for coordinating the release schedule!

[anakin87]

@GunaPalanivel thank you.

Feel free to resolve conflicts. I'll review this PR in the next few days.

We want to include it in the 2.23.0 release.

[anakin87]

Seems OK.

@sjrl could you please review as well, since you know breakpoints better than me?

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
haystack-docs	Ready	Preview, Comment	Jan 14, 2026 11:11am

[sjrl]

Yes this looks okay

[anakin87]

Thank you @GunaPalanivel!