Fix gpexpand 'SyncPackages object has no attribute ret': enqueue OperationWorkerPool operations via items=

[talmacschen-arch]

Summary

Fixes #1825.

OperationWorkerPool.__init__ passed its operations positionally to WorkerPool.__init__:

super(OperationWorkerPool, self).__init__(numWorkers, operations)

But WorkerPool.__init__'s second positional parameter is should_stop, and the work items are the third parameter items:

def __init__(self, numWorkers=16, should_stop=False, items=None, ...):
    ...
    if items is not None:
        for item in items:
            self.addCommand(item)

So operations bound to should_stop (a truthy list) and items stayed None. Consequently no operation was ever added to the work queue, should_stop was set truthy, the worker only ever received the halt command, and the submitted operations never ran. Operation.run() therefore never assigned self.ret, and callers hit:

AttributeError: 'SyncPackages' object has no attribute 'ret'

This breaks the first stage of gpexpand ("Syncing Apache Cloudberry extensions"): the exception is squashed into a WARNING, and — more importantly — package/extension synchronization to new segment hosts silently never runs.

Fix

Pass the operations as the items keyword argument so they are enqueued and should_stop stays False:

super(OperationWorkerPool, self).__init__(numWorkers, items=operations)

This re-applies commit cd3c88f6e1e ("Fix gppkg error: 'SyncPackages' object has no attribute 'ret'."), which was inadvertently reverted by the Merge tag 'REL_16_9' into Cloudberry merge (0f4cf8d5068). On current main, grep -c "items=operations" gpMgmt/bin/gppylib/commands/base.py returns 0.

Testing

• Single-host gpexpand -i <input> -v first stage no longer raises the AttributeError; the SyncPackages operation now actually executes (the -v log shows the worker receiving the operation instead of only a halt command).

See #1825 for the full root-cause analysis and the regression history.

[leborchuk]

We have lost fix https://github.com/apache/cloudberry/pull/1716/changes while rebasing. Maybe we should just cherry-pick fix from PG14_ARCHIVE to main branch?

[tuhaihe]

We have lost fix https://github.com/apache/cloudberry/pull/1716/changes while rebasing. Maybe we should just cherry-pick fix from PG14_ARCHIVE to main branch?

+1.