Fix split fast-path to preserve completion scheduler semantics

[shlokjain2031]

Fixes #6905

Proposed Changes

• Introduces one replay lambda that is used in both:

  • the fast-path (predecessor already done), and
  • deferred continuations (stored and invoked later).

• The replay lambda first inspects the stored completion variant to determine which signal will be emitted:

  • set_value
  • set_error
  • set_stopped

• Before invoking the completion inline, it queries the receiver’s environment for the corresponding completion scheduler.

• If a valid scheduler is found and it supports schedule(), the completion is dispatched through that scheduler using:

  • schedule(scheduler) to obtain a sender
  • then(...) to attach the inline completion invocation
  • start_detached(...) to launch the scheduled sender

• If no suitable scheduler is available, the code falls back to invoking the completion inline, preserving the original behavior.

• This ensures consistent, scheduler-aware behavior in both fast-path and deferred execution paths.

Any background context you want to provide?

Previously, if predecessor_done was true (fast-path), the code directly called set_value, set_error, or set_stopped inline on the downstream receiver. That inline invocation ignored any completion scheduler provided through the receiver’s environment. Ignoring the completion scheduler could break expected execution semantics, since the receiver may require completions to run on a specific scheduler.

Checklist

Not all points below apply to all pull requests.

• I have added a new feature and have added tests to go along with it.
• I have fixed a bug and have added a regression test.
• I have added a test using random numbers; I have made sure it uses a seed, and that random numbers generated are valid inputs for the tests.

[StellarBot]

Can one of the admins verify this patch?

[hkaiser]

@isidorostsa would you have the time to review this PR, please?

[hkaiser]

@isidorostsa ping?

[isidorostsa]

Hey @shlokjain2031, thanks for the pr!

We are in the process of deprecating most of hpx's native senders, and replacing the ones where hpx provides an advantage with cpo specializations on the completion scheduler.

Do you think there is a significant advantage of this implementation over the one found in stdexec?

[hkaiser]

@isidorostsa Could you please have a look?

[hkaiser]

@shlokjain2031 Please have a look at the CI failures.

[hkaiser]

@shlokjain2031 ping?

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}