[lazerg]

Without coroutines, taskWaitMulti() packed each task with zend::array_get(ztasks, i), so it only worked for arrays keyed 0..n-1. With string keys (or any non-list array, like what Octane's concurrently() passes) the lookup returned NULL and php_swoole_server_task_pack() crashed the worker. The coroutine path (taskCo()) iterates the array, which is why it never hit this.

The tasks are now collected in iteration order before dispatch, so the key type no longer matters and results are indexed 0..n-1 like taskCo() returns them. tests/swoole_server/task/task_wait_multi_string_keys.phpt covers string keys and sparse integer keys with enable_coroutine => false; it fails on master (worker gets SIGSEGV) and passes with the fix.

Fixes #6390

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.08%. Comparing base (9cd45e0) to head (6eb98a2).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6405   +/-   ##
=======================================
  Coverage   84.08%   84.08%           
=======================================
  Files         115      115           
  Lines       20237    20237           
  Branches     3637     3637           
=======================================
+ Hits        17016    17017    +1     
+ Misses       3221     3220    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[NathanFreeman]

Thanks for your work, but this fix isn't quite appropriate. According to the Swoole documentation, taskWaitMulti only supports numerically indexed arrays; although associative arrays also work, ambiguity arises when numeric indices and associative keys are mixed.

For example, in the following pseudocode:

<?php
$tasks = [1, 'test' => 'b', 2];
$results = $server->taskWaitMulti($tasks);
foreach ($tasks as $index => $task) {
    var_dump($results[$index] ?? null);
}

When taskWaitMulti returns results in order, the task with value 2 has key 1 in the result array, while in the original task array that task corresponds to key 2. So when using $index to look up values in the result array, key 1 actually retrieves the result originally keyed 'test', causing data misalignment and garbled results.

Similarly, taskWaitMulti cannot correctly handle non-contiguous numerically indexed arrays either, for example:

$tasks = [1 => 1, 3 => 2, 2 => 3];

Since the returned results are renumbered sequentially as 0, 1, 2, they no longer correspond to the original keys, and looking up values in the result array by the original keys will likewise be misaligned.