Prcxi9320

[q434343]

Summary by Sourcery

Enhance liquid handling backends, resource handling, and configuration schemas while removing deprecated Laiyu liquid device implementations.

New Features:

• Add shaker and heater actions plus plate moving support to the PRCXI 9300 backend and device schema, including robotic arm clamp jaw operations and run completion waiting.
• Introduce a SimpleReturn structure and extend liquid handling APIs (set_liquid, aspirate, dispense) to return sample and volume metadata for downstream tracking.
• Allow LiquidHandlerAbstract to construct backend instances from configuration dictionaries, and add a configurable total_height parameter to liquid handler device definitions.

Bug Fixes:

• Correct PRCXI 9300 deck hierarchy usage, axis selection, and plate indexing for tip handling, aspiration, dispense, and mixing operations.
• Preserve per-resource unilabos_extra metadata when resolving resources in the base device node and host node, including mapping sample_uuid to sample_id before sending action goals.
• Fix resource pose construction in the resource tracker and ensure resource mesh and visualization components use pose-based coordinates when present.
• Improve Laiyu pipette controller serial sharing logic so XYZ controller can reuse the pipette connection when no separate XYZ port is configured.
• Normalize mix_times configuration in multiple liquid handler device schemas by changing it from a scalar to an integer array.

Enhancements:

• Update PRCXI 9300 backend run_protocol to wait for solution execution completion and stop automation on reset when needed.
• Add axis parameters to Bioyond API client movement methods so callers explicitly control left/right axis usage.
• Increase Laiyu V backend motion speeds for pick-up, drop, aspirate, and dispense moves.
• Clear pending liquid tracking state on tip drop and discard in the middleware layer.
• Adjust host node resource aggregation to handle nested resource lists correctly.

Documentation:

• Remove embedded Laiyu liquid device code, configuration, drivers, and documentation that are no longer needed.

Tests:

• Add PRCXI 9320 experiment JSON files for testing resource-aware protocols.

Chores:

• Remove an unused transfer_materials_to_reaction_station command from the Bioyond dispensing station device registry.

[sourcery-ai]

Reviewer's Guide

Extends PRCXI 9320/9300 liquid handler capabilities and resource handling by adding heater/shaker/move-plate commands, propagating sample UUIDs through aspiration/dispense and ROS actions, adjusting schemas and coordinate handling, adding axis selection for left/right channels on PRCXI9300, and updating pose/position handling while cleaning up unused Laiyu liquid device code and one bioyond transfer action.

Sequence diagram for aspirate/dispense sample tracking and result packaging

sequenceDiagram
  actor User
  participant HostNode
  participant BaseDeviceNode
  participant LiquidHandlerAbstract
  participant LiquidHandlerMiddleware
  participant Backend as PRCXIBackend
  participant TypeCheck as TypeCheckUtil

  User->>HostNode: request liquid_handler aspirate
  HostNode->>HostNode: assign_sample_id(action_kwargs)
  HostNode->>BaseDeviceNode: send_goal(action_id, goal_msg)
  BaseDeviceNode->>BaseDeviceNode: ACTION wrapper resolves resources
  BaseDeviceNode->>BaseDeviceNode: query resources from bridge
  BaseDeviceNode->>BaseDeviceNode: figure_resource() and copy unilabos_extra.sample_uuid
  BaseDeviceNode->>LiquidHandlerAbstract: aspirate(resources, vols, use_channels,...)
  LiquidHandlerAbstract->>LiquidHandlerMiddleware: aspirate(resources, vols, use_channels,...)
  LiquidHandlerMiddleware->>Backend: aspirate(ops, use_channels,...)
  Backend-->>LiquidHandlerMiddleware: low level hardware steps
  LiquidHandlerMiddleware->>LiquidHandlerMiddleware: build res_samples and res_volumes
  LiquidHandlerMiddleware->>LiquidHandlerMiddleware: pending_liquids_dict[channel] = sample_uuid, volume
  LiquidHandlerMiddleware-->>LiquidHandlerAbstract: SimpleReturn(samples, volumes)
  LiquidHandlerAbstract-->>BaseDeviceNode: SimpleReturn(samples, volumes)

  BaseDeviceNode-->>HostNode: result_value(SimpleReturn)
  HostNode-->>User: result_info_str
  activate TypeCheck
  User->>TypeCheck: get_result_info_str(error, suc, return_value)
  TypeCheck->>TypeCheck: if return_value is dict and has samples
  TypeCheck->>TypeCheck: samples = return_value.pop(samples)
  TypeCheck-->>User: json{error, suc, return_value, samples}
  deactivate TypeCheck

  User->>HostNode: later dispense call
  HostNode->>BaseDeviceNode: send_goal for dispense
  BaseDeviceNode->>LiquidHandlerAbstract: dispense(resources, vols, use_channels,...)
  LiquidHandlerAbstract->>LiquidHandlerMiddleware: dispense(resources, vols, use_channels,...)
  LiquidHandlerMiddleware->>Backend: dispense(ops, use_channels,...)
  Backend-->>LiquidHandlerMiddleware: low level dispense steps
  LiquidHandlerMiddleware->>LiquidHandlerMiddleware: propagate pending_liquids_dict[channel] to target wells
  LiquidHandlerMiddleware-->>LiquidHandlerAbstract: SimpleReturn(samples, volumes)
  LiquidHandlerAbstract-->>BaseDeviceNode: SimpleReturn(samples, volumes)
  BaseDeviceNode-->>HostNode: result_value(SimpleReturn)
  HostNode-->>User: json with samples via get_result_info_str

Loading

Class diagram for updated liquid handler middleware, abstract handler, and PRCXI9300 backend

classDiagram

class SimpleReturn {
  +list samples
  +list volumes
}

class LiquidHandlerBackend {
  <<abstract>>
}

class LiquidHandler {
}

class LiquidHandlerMiddleware {
  +bool _simulator
  +int channel_num
  +dict pending_liquids_dict
  +LiquidHandlerBackend _backend
  +LiquidHandler _simulate_handler
  +Deck deck
  +__init__(backend: LiquidHandlerBackend, deck: Deck, simulator: bool, channel_num: int, joint_config)
  +async drop_tips(tip_spots, use_channels, offsets, allow_nonzero_volume, backend_kwargs)
  +async discard_tips(use_channels, allow_nonzero_volume, offsets, backend_kwargs)
  +async aspirate(resources, vols, use_channels, offsets, flow_rates, use_anti_droplet, blow_out_air_volume, spread, backend_kwargs) SimpleReturn
  +async dispense(resources, vols, use_channels, offsets, flow_rates, use_anti_droplet, blow_out_air_volume, spread, backend_kwargs) SimpleReturn
}

class LiquidHandlerAbstract {
  +bool support_pick_up_tip
  +bool support_drop_tips
  +bool support_touch_tip
  +BaseROS2DeviceNode _ros_node
  +dict group_info
  +__init__(backend: LiquidHandlerBackend|dict, deck: Deck, simulator: bool, channel_num: int, total_height: float)
  +post_init(ros_node: BaseROS2DeviceNode)
  +set_liquid(wells: list~Well~, liquid_names: list~str~, volumes: list~float~) SimpleReturn
}

class PRCXI9320Device {
  +__init__(backend: LiquidHandlerBackend, deck: Deck, simulator: bool, channel_num: int, is_9320: bool)
  +post_init(ros_node: BaseROS2DeviceNode)
  +set_liquid(wells: list~Well~, liquid_names: list~str~, volumes: list~float~) SimpleReturn
  +async move_to(well: Well, dis_to_top: float, channel: int)
  +async shaker_action(time: int, module_no: int, amplitude: int, is_wait: bool)
  +async heater_action(temperature: float, time: int)
  +async move_plate(plate: Plate, to: Resource, intermediate_locations: list~Coordinate~, pickup_offset: Coordinate, destination_offset: Coordinate, drop_direction: GripDirection, pickup_direction: GripDirection, pickup_distance_from_top: float, backend_kwargs)
}

class PRCXI9300Backend {
  +bool debug
  +int _num_channels
  +object _execute_setup
  +str axis
  +list steps_todo_list
  +__init__(deck: Deck, simulation: bool, setup, port: str, channel_num: int, debug: bool)
  +async shaker_action(time: int, module_no: int, amplitude: int, is_wait: bool)
  +async pick_up_resource(pickup: ResourcePickup, backend_kwargs)
  +async drop_resource(drop: ResourceDrop, backend_kwargs)
  +async heater_action(temperature: float, time: int)
  +run_protocol() bool
  +async setup()
  +async stop()
  +async pick_up_tips(ops: list~Pickup~, use_channels: list~int~)
  +async drop_tips(ops: list~Drop~, use_channels: list~int~)
  +async mix(targets, vols, mix_liquid_height, mix_times, mix_vol, mix_rate, mix_stage, none_keys)
  +async aspirate(ops: list~SingleChannelAspiration~, use_channels: list~int~)
  +async dispense(ops: list~SingleChannelDispense~, use_channels: list~int~)
  +async move_picked_up_resource(move: ResourceMove)
}

class PRCXI9300ApiClient {
  +start() bool
  +wait_for_finish() bool
  +Load(dosage: int, plate_no: int, is_whole_plate: bool, hole_col: int, hole_row: int, balance_height: int, plate_or_hole_num: str, assist_fun1: str, assist_fun2: str, assist_fun3: str, assist_fun4: str, assist_fun5: str, liquid_method: str, axis: str) dict
  +Imbibing(dosage: int, plate_no: int, is_whole_plate: bool, hole_col: int, hole_row: int, balance_height: int, plate_or_hole_num: str, assist_fun1: str, assist_fun2: str, assist_fun3: str, assist_fun4: str, assist_fun5: str, liquid_method: str, axis: str) dict
  +Tapping(dosage: int, plate_no: int, is_whole_plate: bool, hole_col: int, hole_row: int, balance_height: int, plate_or_hole_num: str, assist_fun1: str, assist_fun2: str, assist_fun3: str, assist_fun4: str, assist_fun5: str, liquid_method: str, axis: str) dict
  +Blending(dosage: int, plate_no: int, is_whole_plate: bool, hole_col: int, hole_row: int, balance_height: int, plate_or_hole_num: str, assist_fun1: str, assist_fun2: str, assist_fun3: str, assist_fun4: str, assist_fun5: str, liquid_method: str, axis: str) dict
  +UnLoad(dosage: int, plate_no: int, is_whole_plate: bool, hole_col: int, hole_row: int, balance_height: int, plate_or_hole_num: str, assist_fun1: str, assist_fun2: str, assist_fun3: str, assist_fun4: str, assist_fun5: str, liquid_method: str, axis: str) dict
  +clamp_jaw_pick_up(plate_no: int, is_whole_plate: bool, balance_height: int) dict
  +clamp_jaw_drop(plate_no: int, is_whole_plate: bool, balance_height: int) dict
  +shaker_action(time: int, module_no: int, amplitude: int, is_wait: bool) dict
}

LiquidHandlerMiddleware --|> LiquidHandler
LiquidHandlerAbstract --|> LiquidHandlerMiddleware
PRCXI9320Device --|> LiquidHandlerAbstract
PRCXI9300Backend ..|> LiquidHandlerBackend
PRCXI9300Backend o--> PRCXI9300ApiClient : api_client

SimpleReturn <.. LiquidHandlerMiddleware : returns
SimpleReturn <.. LiquidHandlerAbstract : returns
SimpleReturn <.. PRCXI9320Device : returns

Loading

File-Level Changes

Change	Details	Files
Update liquid handler schemas to support array mix repetitions, new total_height configuration, and PRCXI-specific heater/shaker/move-plate commands.	Change mix_times defaults from scalar to single-element list in multiple liquid handler YAMLs. Update mix_times JSON schema from integer to array of integers with bounds. Add total_height numeric property with default 310 to liquid_handler configuration. Register PRCXI auto-heater_action, auto-shaker_action, and move_plate commands with detailed goal/result schemas.	unilabos/registry/devices/liquid_handler.yaml unilabos/registry/devices/liquid_handler.prcxi.yaml unilabos/registry/devices/laiyu_liquid.yaml
Enhance PRCXI 9300/9320 backend to support shaker/heater actions, robotic plate movement via clamp jaw, synchronous run completion, and per-axis (left/right) operation for core liquid handling steps.	Derive tablet info from child resources instead of direct _unilabos_state and adjust numbering for PRCXI 9320. Expose shaker_action, heater_action, and move_plate async methods on PRCXI front-end delegating to backend or parent implementation with target_plate_number passthrough. Implement shaker_action, pick_up_resource, and drop_resource in PRCXI9300Backend using new api_client methods and plate number resolution from resource graph. Add clamp_jaw_pick_up, clamp_jaw_drop, and shaker_action step builders to API client; introduce wait_for_finish to poll step_state_list and integrate into run_protocol. Introduce axis selection logic based on use_channels and thread through to Load/Imbibing/Tapping/UnLoad/Blending, while fixing deck/plate indexing in tip, aspirate, dispense, and mix operations. Ensure PRCXI9300 setup stops automation before reset and make move_picked_up_resource a no-op instead of NotImplemented.	unilabos/devices/liquid_handling/prcxi/prcxi.py
Propagate sample UUIDs through ROS resource resolution and liquid handling operations, and surface sample metadata in generic result payloads.	Introduce SimpleReturn TypedDict and use it as return type for set_liquid and dispense-related APIs. Track pending_liquids_dict in LiquidHandlerMiddleware: populate on aspirate, clear on drop/discard tips, and use to propagate sample_uuid to dispense targets while returning structured sample/volume info. Modify LiquidHandlerAbstract.init to optionally construct backend from a dict type string and return SimpleReturn in set_liquid with sample metadata. When querying resources in BaseROS2DeviceNode.ACTION, attach sample_uuid from RPC data, then preserve unilabos_extra when mapping to local resources. Before sending ROS action goals in HostNode, recursively translate sample_uuid fields to sample_id outside unilabos_extra. Extend get_result_info_str to strip and expose samples from return_value into a top-level samples field.	unilabos/devices/liquid_handling/liquid_handler_abstract.py unilabos/ros/nodes/base_device_node.py unilabos/ros/nodes/presets/host_node.py unilabos/utils/type_check.py
Normalize resource pose handling and visualization to use pose-based structures with size info, and update mesh/resource visualization consumers accordingly.	In ResourceTracker.get_resource_instance_from_dict, synthesize pose.position and pose.size from legacy position/config fields when present. Update ResourceMeshManager to read position and rotation from pose instead of position. Adjust resource visualization to handle both legacy position-based nodes and new pose-based nodes, preferring pose when available.	unilabos/ros/nodes/resource_tracker.py unilabos/ros/nodes/presets/resource_mesh_manager.py unilabos/device_mesh/resource_visalization.py
Improve Laiyu pipette controller and backend motion behavior and remove obsolete Laiyu device implementation in favor of registry-based configuration.	Store pipette serial port on controller, reuse it for XYZ controller when xyz_port matches pipette port, and increase motion speeds for pick/drop tips and aspirate/dispense moves. Remove the standalone laiyu_liquid Python package (backend, controllers, drivers, tests, and docs) in favor of configuration-only usage.	unilabos/devices/liquid_handling/laiyu/controllers/pipette_controller.py unilabos/devices/liquid_handling/laiyu/backend/laiyu_v_backend.py unilabos/devices/laiyu_liquid/**
Clean up an unused bioyond dispensing action and add PRCXI test experiment configs.	Remove transfer_materials_to_reaction_station UniLabJsonCommand from bioyond_dispensing_station registry. Add PRCXI 9320 experiment JSON stubs for testing with resources.	unilabos/registry/devices/bioyond_dispensing_station.yaml unilabos/test/experiments/prcxi_9320_with_res.json unilabos/test/experiments/prcxi_9320_with_res_test.json

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 5 issues, and left some high level feedback:

• In _handle_future_exception (base_device_node.py), the else branch uses parent_resource(r) but r is only defined inside the if isinstance(rs, list) block; this should likely be parent_resource(rs) to avoid a NameError.
• The new PRCXI9300Backend.heater_action currently just prints and returns without appending a step or calling the API client (the real call is commented out), which means heater actions will be silently ignored; consider implementing it consistently with shaker_action.
• In ResourceTracker.get_resource_instance_from_dict, constructing pose['size'] reads content['config'] without ensuring the config key exists or is a dict, which can raise a KeyError or AttributeError for minimal resource dicts; adding a safe default or guard around content['config'] would make this more robust.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `_handle_future_exception` (base_device_node.py), the `else` branch uses `parent_resource(r)` but `r` is only defined inside the `if isinstance(rs, list)` block; this should likely be `parent_resource(rs)` to avoid a NameError.
- The new `PRCXI9300Backend.heater_action` currently just prints and returns without appending a step or calling the API client (the real call is commented out), which means heater actions will be silently ignored; consider implementing it consistently with `shaker_action`.
- In `ResourceTracker.get_resource_instance_from_dict`, constructing `pose['size']` reads `content['config']` without ensuring the `config` key exists or is a dict, which can raise a KeyError or AttributeError for minimal resource dicts; adding a safe default or guard around `content['config']` would make this more robust.

## Individual Comments

### Comment 1
<location> `unilabos/devices/liquid_handling/prcxi/prcxi.py:441-450` </location>
<code_context>
+    async def shaker_action(self, time: int, module_no: int, amplitude: int, is_wait: bool):
+        return await self._unilabos_backend.shaker_action(time, module_no, amplitude, is_wait)
+
+    async def heater_action(self, temperature: float, time: int):
+        return await self._unilabos_backend.heater_action(temperature, time)  
+    async def move_plate(
</code_context>

<issue_to_address>
**issue (bug_risk):** heater_action now only logs and does not invoke the backend API, which likely breaks the feature.

This should invoke the backend heater action (as `shaker_action` does with `_unilabos_backend`). If the intent is still to control the device, ensure `heater_action` calls the backend rather than only logging/returning `None`, and keep the log only as an addition if needed.
</issue_to_address>

### Comment 2
<location> `unilabos/devices/liquid_handling/liquid_handler_abstract.py:32-34` </location>
<code_context>

 from unilabos.ros.nodes.base_device_node import BaseROS2DeviceNode
-
+class SimpleReturn(TypedDict):
+    samples: list
+    volumes: list

 class LiquidHandlerMiddleware(LiquidHandler):
</code_context>

<issue_to_address>
**issue (bug_risk):** SimpleReturn definition and usage are inconsistent in simulator vs non-simulator paths.

`aspirate`, `dispense`, and `set_liquid` now return `SimpleReturn`, but their simulator branches still return the simulator backend’s native type. This forces callers to handle two different return shapes based on `self._simulator`. Either adapt simulator results into `SimpleReturn` as well or clearly split these APIs so callers don’t need to perform type checks on the return value.
</issue_to_address>

### Comment 3
<location> `unilabos/devices/liquid_handling/liquid_handler_abstract.py:138-140` </location>
<code_context>
                 tip_spots, use_channels, offsets, allow_nonzero_volume, **backend_kwargs
             )
-        return await super().drop_tips(tip_spots, use_channels, offsets, allow_nonzero_volume, **backend_kwargs)
+        await super().drop_tips(tip_spots, use_channels, offsets, allow_nonzero_volume, **backend_kwargs)
+        self.pending_liquids_dict = {}
+        return 

     async def return_tips(
</code_context>

<issue_to_address>
**issue (bug_risk):** drop_tips and discard_tips now return None for non-simulator mode, which may break callers expecting a backend result.

These methods used to return the value from `super().drop_tips` / `super().discard_tips`, but now in non-simulator mode they await the super call, clear `pending_liquids_dict`, and explicitly return `None`. Any caller depending on the returned value (even just its truthiness) will see a behavior change, and only on real hardware. Please either keep returning the super result while clearing `pending_liquids_dict`, or clearly document and propagate this behavioral change so it’s consistent across simulator and non-simulator paths.
</issue_to_address>

### Comment 4
<location> `unilabos/ros/nodes/base_device_node.py:1278-1281` </location>
<code_context>
                         seen = set()
                         unique_resources = []
                         for rs in akv:  # todo: 这里目前只支持plr的类型
-                            res = self.resource_tracker.parent_resource(rs)  # 获取 resource 对象
+                            if isinstance(rs, list):
+                                for r in rs:
+                                    res = self.resource_tracker.parent_resource(r)  # 获取 resource 对象
+                            else:
+                                res = self.resource_tracker.parent_resource(r)
</code_context>

<issue_to_address>
**issue (bug_risk):** The else branch in the resource collection logic uses an undefined variable `r`.

In `_handle_future_exception`, within `for rs in akv`, `r` is only defined inside the `if isinstance(rs, list)` block. In the `else` branch, `parent_resource(r)` uses `r` even though it’s undefined there; this will raise an `UnboundLocalError` whenever `rs` is not a list. The `else` branch should use `rs` (or the loop should be restructured) so that the correct variable is passed to `parent_resource` in all cases.
</issue_to_address>

### Comment 5
<location> `unilabos/utils/type_check.py:81-85` </location>
<code_context>
         JSON字符串格式的结果信息
     """
-    result_info = {"error": error, "suc": suc, "return_value": return_value}
+    samples = None
+    if isinstance(return_value, dict):
+        if "samples" in return_value:
+            samples = return_value.pop("samples")
+    result_info = {"error": error, "suc": suc, "return_value": return_value, "samples": samples}

     return json.dumps(result_info, ensure_ascii=False, cls=ResultInfoEncoder)
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Mutating `return_value` by popping `samples` can surprise callers that reuse the dict.

This mutates the caller’s dict: after `get_result_info_str` returns, `return_value` will no longer contain `samples`. To avoid this side effect, copy the dict first (e.g. `rv = dict(return_value)`), pop from the copy, and use that in the JSON instead of changing the original.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): heater_action now only logs and does not invoke the backend API, which likely breaks the feature.

This should invoke the backend heater action (as shaker_action does with _unilabos_backend). If the intent is still to control the device, ensure heater_action calls the backend rather than only logging/returning None, and keep the log only as an addition if needed.

[sourcery-ai]

issue (bug_risk): SimpleReturn definition and usage are inconsistent in simulator vs non-simulator paths.

aspirate, dispense, and set_liquid now return SimpleReturn, but their simulator branches still return the simulator backend’s native type. This forces callers to handle two different return shapes based on self._simulator. Either adapt simulator results into SimpleReturn as well or clearly split these APIs so callers don’t need to perform type checks on the return value.

[sourcery-ai]

issue (bug_risk): drop_tips and discard_tips now return None for non-simulator mode, which may break callers expecting a backend result.

These methods used to return the value from super().drop_tips / super().discard_tips, but now in non-simulator mode they await the super call, clear pending_liquids_dict, and explicitly return None. Any caller depending on the returned value (even just its truthiness) will see a behavior change, and only on real hardware. Please either keep returning the super result while clearing pending_liquids_dict, or clearly document and propagate this behavioral change so it’s consistent across simulator and non-simulator paths.

[sourcery-ai]

issue (bug_risk): The else branch in the resource collection logic uses an undefined variable r.

In _handle_future_exception, within for rs in akv, r is only defined inside the if isinstance(rs, list) block. In the else branch, parent_resource(r) uses r even though it’s undefined there; this will raise an UnboundLocalError whenever rs is not a list. The else branch should use rs (or the loop should be restructured) so that the correct variable is passed to parent_resource in all cases.

[sourcery-ai]

suggestion (bug_risk): Mutating return_value by popping samples can surprise callers that reuse the dict.

This mutates the caller’s dict: after get_result_info_str returns, return_value will no longer contain samples. To avoid this side effect, copy the dict first (e.g. rv = dict(return_value)), pop from the copy, and use that in the JSON instead of changing the original.

[q434343]

prcix9320