Type design (High value): execution_id: str | None = None models the field as optional with a None default — which re-permits the exact NULL state this PR exists to eliminate. Its sibling execution-scoped id workflow_id (line 222) is required (str, no default) and validated in __post_init__; execution_id is always available at the only call site (destination_connector.py:1836 reads self.execution_id unconditionally), so it has the same lifecycle.

Suggested: make it required and move it next to workflow_id, then add to the existing __post_init__ validation block:

if not self.execution_id:
    raise ValueError("QueueResult requires a valid execution_id")

This closes the NULL hole at construction instead of leaving it to chance. (The test_execution_id_defaults_to_none_but_key_present test currently encodes the optional behavior as acceptable and would need updating — which is correct.)

If backward-compat with unknown external callers is mandatory, at minimum add a logger.warning in __post_init__ when execution_id is falsy, so a NULL write is logged rather than silent.

Maintainability (Medium): to_dict() is a hand-maintained serializer — every field that the consumer reads must be manually mirrored here. A field added to the dataclass but forgotten here fails silently as a downstream NULL, which is precisely this ticket's failure mode. Consider replacing the hand-written body with dataclasses.asdict(self) plus the one transform it needs (status → status.value), so adding a field automatically propagates to the wire format. Not required for this PR, but it removes the recurring two-place-edit hazard.

Test gap (criticality 7 — highest-value missing test): This line is the entire point of the PR, and it has no test. The two new tests only exercise QueueResult(...).to_dict() with execution_id passed in by hand, so they still pass if this kwarg is dropped (→ defaults to None → hitl_queue.execution_id back to NULL) or fat-fingered to self.file_execution_id (the adjacent line). Suggest a test that exercises _push_data_to_queue (line 1759) with the I/O helpers mocked and asserts the dict handed to the enqueue boundary carries the connector's execution_id — using a value distinct from file_execution_id so an adjacent-field swap is detectable.

Comment accuracy (comment-rot risk): This comment asserts backend behavior — that it reads message["execution_id"] and persists hitl_queue.execution_id. That consumer is pluggable_apps.manual_review_v2, which is not in this repo (only referenced via guarded imports), so the claim can't be verified or kept honest here. It also contradicts the test file's comment, which describes the access as .get("execution_id") (no-raise) rather than subscript. Suggest scoping the comment to what this repo controls and naming where the other half lives, e.g.: # Carried into the HITL queue message so the manual-review consumer (pluggable_apps.manual_review_v2, separate codebase) can populate hitl_queue.execution_id. The key name must stay in sync with that consumer. Drop the assertion about which accessor the backend uses; the durable local fact is that to_dict() always emits the key (None when unset).

Docstring scope: "These tests pin that contract" overstates what's covered — the tests only exercise the producer's QueueResult.to_dict() serialization, not the backend persistence half (consumer + hitl_queue.execution_id column live out-of-tree). Suggest scoping to the verifiable half: "pin the producer half of that contract — that to_dict() emits a key named exactly execution_id." Leave the consumer/column behavior as context rather than something the tests guarantee.