fix: SELECT.one also returns undefined

[johannes-vogel]

Fix: SELECT.one Return Type Now Includes undefined

Bug Fix

🐛 Corrected the return type of SELECT.one overloads to accurately reflect that the result can also be undefined (in addition to null), matching the actual runtime behavior.

Changes

• apis/ql.d.ts: Updated multiple SELECT_one overload signatures to change the awaited return type from T | null to T | null | undefined. This affects the following overloads:
  • (entityType: T, projection?) — with ArrayConstructable
  • (entityType: T, primaryKey, projection?) — with ArrayConstructable
  • (entity: T[], projection?)
  • (entity: T[], primaryKey, projection?)
  • (entity: { new(): T }, projection?)
  • (entity: { new(): T }, primaryKey, projection?)

• 🔄 Regenerate and Update Summary

PR Bot Information

Version: 1.28.2

• LLM: anthropic--claude-4.6-sonnet
• Output Template: Default Template
• File Content Strategy: Full file content
• Event Trigger: pull_request.ready_for_review
• Summary Prompt: Default Prompt
• Correlation ID: 00ad88e0-851b-11f1-8335-bd0f27a90554

[hyperspace-pr-bot]

The line 179 is not in the diff (it was not changed), so a review comment cannot be posted on it directly. The inconsistency is still worth mentioning in the summary.

The PR adds | undefined to all SELECT_one return types. The existing discussion thread on line 155 is already actively debating the core trade-off (whether null should be kept or replaced entirely, and whether matching plugin behaviour justifies the union). The one additional technical observation — that the primary-key overload in SELECT_from (line 179) still returns only T | null without undefined, creating an asymmetry with the newly widened SELECT_one overloads — cannot be posted as a diff comment because that line is unchanged. This asymmetry should be addressed in the ongoing discussion or in a follow-up.

Summary: The change is minimal and targeted, but the existing review thread highlights an unresolved design question (keep both null and undefined, or consolidate to one) that should be settled before merging. Additionally, consider whether the analogous primary-key overload in SELECT_from needs the same | undefined treatment for a consistent API contract.

PR Bot Information

Version: 1.28.2

• File Content Strategy: Full file content
• Event Trigger: pull_request.ready_for_review
• LLM: anthropic--claude-4.6-sonnet
• Correlation ID: 00ad88e0-851b-11f1-8335-bd0f27a90554

[daogrady]

Thank you! :)