Time Object ID Lookup Endpoint#4807
Conversation
|
@codex please review this branch |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03adf43620
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| { | ||
| List<FlowTimeObject> result = await apiConnection.SendQueryAsync<List<FlowTimeObject>>( | ||
| FlowQueries.getFlowTimeObjectId, | ||
| BuildLookupQueryVariables(visibleInRequest, ("start_time", startTime), ("end_time", endTime))) ?? []; |
There was a problem hiding this comment.
Support one-sided time object lookups
When the flow time object is open-ended (only start_time or only end_time is set), this lookup cannot resolve it because the new request requires both bounds and the query always emits _eq predicates for both fields. The existing flow creation path treats one-sided time objects as valid (FlowDbCreator.ResolveOrCreateTimeObject creates one when either bound is present, and FlowHashGenerator.GenerateTimeObjectHash allows either bound), so API clients trying to look up a deadline-only or start-only object will get a 400 for the omitted field or no match instead of the existing id. Make the bounds nullable and generate _is_null predicates for missing bounds.
Useful? React with 👍 / 👎.
# Conflicts: # roles/tests-unit/files/FWO.Test/FlowQueriesTest.cs
|
@codex please review this |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: afa12027d5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return errorResult!; | ||
| } | ||
|
|
||
| if (request.StartTime.HasValue && request.EndTime.HasValue && request.StartTime > request.EndTime) |
There was a problem hiding this comment.
Reject time ID lookups with no bounds
When a caller posts {} or only filter, this validation still falls through to GetTimeObjectIdAsync with both timestamps null, which builds start_time: {_is_null: true} and end_time: {_is_null: true} and returns the first matching custom/unbounded time object. The flow model treats null/null time objects as non-deterministic custom objects (FlowHashGenerator.GenerateTimeObjectHash refuses them), so an omitted range can resolve to an unrelated ID instead of being rejected; require at least one of startTime or endTime before querying.
Useful? React with 👍 / 👎.
|
@codex review this please |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|



Adds a new
GetTimeObjectIdendpoint to the flow catalog controller, mirroring the existing address and service object ID lookups. The endpoint validates the request in the same schema-driven way, honors thevisibleInRequestfilter, and returns the matching time object ID and name when thestartTime/endTimerange exists in the DB.