H-5732: Support integration Flows, add basic aviation integration #8213
Conversation
β¦ run flows, and related changes
github-actions
bot
added
area/deps
Codecov Reportβ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8213 +/- ##
==========================================
+ Coverage 58.90% 59.02% +0.12%
==========================================
Files 1193 1187 -6
Lines 112723 112486 -237
Branches 5013 4939 -74
==========================================
Hits 66394 66394
+ Misses 45571 45334 -237
Partials 758 758
Flags with carried forward coverage won't be shown. Click here to find out more. β View full report in Codecov by Sentry. π New features to boost your workflow:
|
PR SummaryIntroduces a shared Flow engine and enables Integration flows alongside AI flows.
Written by Cursor Bugbot for commit ea57477. This will update automatically on new commits. Configure here. |
|
This pull request is too large for Augment to review. The PR exceeds the maximum size limit of 100000 tokens (approximately 400000 characters) for automated code review. Please consider breaking this PR into smaller, more focused changes. |
There was a problem hiding this comment.
Pull request overview
This PR refactors the Flow execution system to support both AI and Integration workflows, and adds a basic aviation integration using FlightAware's AeroAPI and Flightradar24 APIs.
Key Changes:
- Extracts shared Flow orchestration logic into
@local/hash-backend-utilsfor reuse across workers - Adds
FlowTypeenum ("ai" | "integration") to distinguish workflow types - Implements aviation integration with scheduled flight retrieval and entity persistence
- Introduces new entity types: Aircraft, Airline, Airport, Flight with associated link types
Reviewed changes
Copilot reviewed 115 out of 118 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
libs/@local/hash-isomorphic-utils/src/flows/types.ts |
Adds generic type parameters to Flow types for action definition constraints |
libs/@local/hash-isomorphic-utils/src/flows/action-definitions.ts |
Splits action definitions into AI and Integration variants |
libs/@local/hash-backend-utils/src/flows/process-flow-workflow.ts |
Extracted shared workflow processing logic from AI worker |
apps/hash-integration-worker/src/workflows/run-flow-workflow.ts |
New integration worker flow implementation |
libs/@local/hash-backend-utils/src/integrations/aviation/** |
Aviation integration clients and entity mapping logic |
libs/@local/hash-isomorphic-utils/src/system-types/flight.ts |
Generated TypeScript types for aviation entities (677 lines) |
libs/@local/hash-isomorphic-utils/src/flows/integration-flow-definitions.ts |
Flow definition for scheduled flights retrieval |
π‘ Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| if (flowType === FlowType.Ai) { | ||
| if (!("dataSources" in params)) { | ||
| throw Error.badRequest("Data sources are required for AI flows"); | ||
| } |
There was a problem hiding this comment.
In-place object property check always prevents AI flows
In startFlow, the condition !("dataSources" in params) always evaluates to true for AI flows because params is initialized as an object literal without that property. This causes every AI flow request to throw a badRequest error, incorrectly claiming that mandatory data sources are missing.
| export const goalFlowDefinitionWithReportAndSpreadsheetDeliverable: FlowDefinition<AiFlowActionDefinitionId> = | ||
| { | ||
| ...goalFlowDefinition, | ||
| type: "ai", |
There was a problem hiding this comment.
Goal flow ID array incorrectly contains entire object
The goalFlowDefinitionIds array incorrectly includes the entire goalFlowDefinitionWithReportAndSpreadsheetDeliverable object instead of its flowDefinitionId string. This causes identifier checks like goalFlowDefinitionIds.includes(id) to fail for this specific flow, which prevents it from being correctly identified as a goal flow in the UI.
| export const goalFlowDefinitionWithReportAndSpreadsheetDeliverable: FlowDefinition<AiFlowActionDefinitionId> = | ||
| { | ||
| ...goalFlowDefinition, | ||
| type: "ai", |
There was a problem hiding this comment.
Goal flow ID array incorrectly contains entire object
The goalFlowDefinitionIds array incorrectly includes the entire goalFlowDefinitionWithReportAndSpreadsheetDeliverable object instead of its flowDefinitionId string. This causes identifier checks like goalFlowDefinitionIds.includes(id) to fail for this specific flow, which prevents it from being correctly identified as a goal flow in the UI.
| Icon={PlaySolidIcon} | ||
| onClick={onRunFlowClicked} | ||
| pending={waitingToRun} | ||
| pending={false} |
There was a problem hiding this comment.
Flow run button missing loading state and error handling
The flow execution button in Topbar has lost its loading state and error handling. The pending prop is now hardcoded to false, and the try...catch block was removed from onRunFlowClicked. This allows users to trigger multiple simultaneous flow runs and leaves potential API failures unhandled in the UI.
Additional Locations (1)
| Icon={PlaySolidIcon} | ||
| onClick={onRunFlowClicked} | ||
| pending={waitingToRun} | ||
| pending={false} |
There was a problem hiding this comment.
Flow run button missing loading state and error handling
The flow execution button in Topbar has lost its loading state and error handling. The pending prop is now hardcoded to false, and the try...catch block was removed from onRunFlowClicked. This allows users to trigger multiple simultaneous flow runs and leaves potential API failures unhandled in the UI.
Additional Locations (1)
π What is the purpose of this PR?
We have an in-app "Flows" feature β modular workflows made up of discrete, composable actions.
These are executed via Temporal, via logic that handles calling the right actions in the right order with the right inputs (without knowing what the actions actually are).
This was previously implemented and only supported inside of the AI Temporal worker, for AI-related flows. We have an 'Integration' worker, but its workflows were specific hard-coded series of actions, rather than taking the modular approach.
In preparation for adding more data integrations, the bulk of this PR deals with splitting out the Flow logic from the AI worker into a shared place, and adding support for the Flow approach to the Integration worker.
Note that while the general orchestration logic is shared, the two workers deal with different sorts of actions, and Flows can either be made up of actions supported by the AI worker or actions supported by the Integration worker, but not a mix. This is a starting position and can be changed βΒ it is technically possible to have a workflow made up of a mixture. We can update as necessary when required.
The PR also adds a basic integration for aviation-related data βΒ getting scheduled flights for specific airports, and their live position.
π« Blocked by
Pre-Merge Checklist π
π’ Has this modified a publishable library?
This PR:
π Does this require a change to the docs?
The changes in this PR:
πΈοΈ Does this require a change to the Turbo Graph?
The changes in this PR:
Next ups
π‘ What tests cover this?