Python: extract_range(preserve_pairs=True) reorders messages around a call/result pair (fix open as PR #14165, unlinked)

[VANDRANKI]

Describe the bug

extract_range() in python/semantic_kernel/contents/history_reducer/chat_history_reducer_utils.py (used by ChatHistorySummarizationReducer with preserve_pairs=True) scrambles the chronological order of the extracted messages whenever a function-call/result pair has other messages interleaved between them.

Current main:

extracted: list[ChatMessageContent] = []
i = 0
while i < len(sliced):
    idx = sliced[i]
    msg = history[idx]
    ...
    if preserve_pairs and idx in pair_map:
        paired_idx = pair_map[idx]
        if start <= paired_idx < end:
            ...
            extracted.append(msg)
            if paired_idx > idx:
                extracted.append(history[paired_idx])
                if paired_idx in sliced:
                    sliced.remove(paired_idx)
            ...

When the loop reaches the earlier half of a pair (the call), it immediately appends the later half (the result) right behind it in extracted, then removes the result's index from sliced so it isn't visited again at its natural position. That is what moves the result out of its original place whenever anything sits between the call and the result.

To Reproduce

Ran against the actual installed semantic-kernel package (1.44.1; chat_history_reducer_utils.py confirmed byte-identical to the current main file before running):

from semantic_kernel.contents.chat_message_content import ChatMessageContent
from semantic_kernel.contents.function_call_content import FunctionCallContent
from semantic_kernel.contents.function_result_content import FunctionResultContent
from semantic_kernel.contents.utils.author_role import AuthorRole
from semantic_kernel.contents.history_reducer.chat_history_reducer_utils import extract_range

msg0 = ChatMessageContent(role=AuthorRole.USER, content="What's the weather in Paris and Tokyo?")
msg1 = ChatMessageContent(role=AuthorRole.ASSISTANT, items=[FunctionCallContent(id="call_paris", name="get_weather")])
msg2 = ChatMessageContent(role=AuthorRole.USER, content="also check the forecast for tomorrow")
msg3 = ChatMessageContent(role=AuthorRole.TOOL, items=[FunctionResultContent(id="call_paris", name="get_weather", result="15C")])
msg4 = ChatMessageContent(role=AuthorRole.ASSISTANT, content="Paris is 15C.")
history = [msg0, msg1, msg2, msg3, msg4]

out = extract_range(history, start=0, end=5, preserve_pairs=True)
for m in out:
    print(m.role, m.content or [getattr(it, "id", None) for it in m.items])

Output:

AuthorRole.USER What's the weather in Paris and Tokyo?
AuthorRole.ASSISTANT ['call_paris']
AuthorRole.TOOL ['call_paris']
AuthorRole.USER also check the forecast for tomorrow
AuthorRole.ASSISTANT Paris is 15C.

The tool result (originally index 3, after the interleaved user message at index 2) is pulled forward to sit right after the call, and the interleaved user message is pushed after it - the extracted order no longer matches history[0:5].

Expected behavior

extract_range(history, 0, 5, preserve_pairs=True) should return the messages in their original order (minus anything actually filtered out), i.e. history[0], history[1], history[2], history[3], history[4] unchanged, since nothing here should be filtered.

Platform

• Language: Python
• Source: pip package semantic-kernel==1.44.1, confirmed unchanged on current main
• File: python/semantic_kernel/contents/history_reducer/chat_history_reducer_utils.py, function extract_range()

Additional context

There is already an open, unmerged fix for exactly this for this: PR #14165 ("Python: Fix extract_range reordering messages when preserving function call/result pairs"), open since 2026-07-18, which rewrites the loop as a single forward pass so messages are never moved out of position. It has no linked issue, which may be why it has sat without a maintainer review beyond the automated Copilot pass. Filing this so the fix has something to attach to.

Note: while reviewing that PR's diff I found the rewritten version still shares the same pair_map[cidx] = ridx construction as current main, which has a separate, still-open dict-collision problem when a call message contains more than one function call (multiple results mapping to the same call index) - reported separately since it's a distinct bug from this ordering issue and reproduces on both the current code and PR #14165's rewrite.