-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Add routing logic for check and discover workflow #21822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* migrated SAT to strictness level * fixed expected records * revert file from another source * changed extension to txt * changed extension to txt
…due to a config issue (#21144) * [19998] Destination-Bigquery: Added an explicit error message in sync fails due to a config issue
* disable tox * rename steps * revert changes on experimental workflow * do not install tox
Because there is a lot of CVEs in those releases. Co-authored-by: Topher Lubaway <[email protected]>
* add docs * add schema link * update based on feedback
* improve serviceTypeDropdownOption selector * add test ids to PathPopout component(s) * add unique id's to table dropdowns * extend submitButtonClick to support optional click options * update dropdown(pathPopout) matchers * add test-id to Overlay component * remove redundant function brackets * revert changes onSubmit button click * fix dropDown overlay issue * move all duplicated intercepters to beforeEach * add test id's to Connections, Sources and Destinations tables * add table helper functions * update source page actions * intercepter fixes * update createTestConnection function with optional replication settings * remove extra Connection name check * replace "cypress-postgres" with "pg-promise" npm package * update cypress config * Revert "update createTestConnection function with optional replication settings" This reverts commit 8e47c78. * Revert "remove extra Connection name check" This reverts commit dfb19c7. * replace openSourceDestinationFromGrid with specific selector * replace openSourceDestinationFromGrid with specific selector * turn on test * add test-id's * fix selectors * update test * update test snapshots * fix lost data-testid after resolve merge conflicts * remove extra check * move clickOnCellInTable helper to common.ts file * remove empty line and comments * fix dropdownType * replace partial string check with exact * extract interceptors and waiters to separate file * fix selector for predefined PK * fix selector * add comment regarding dropdown
import java.util.Map; | ||
|
||
@Singleton | ||
public class DefaultTaskQueueMapper implements TaskQueueMapper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would be easier to maintain a different approach here - my rough idea is that instead of maintaining a separate map for every job type going forward and adding a new RouterService method for each job type, perhaps the RouterService and TaskQueueMapper should be more opinionated and force a standard task queue format based on the geography and TemporalJobType name.
So, instead of having a separate map and method for every type of job, we could instead have a single method getTaskQueue(TemporalJobType, Geography)
which returns the appropriate task queue. The DefaultTaskQueueMapper could simply return the TemporalJobType name without considering the Geography at all, and the CloudTaskQueueMapper could have a map from Geography
to taskQueueSuffix
that it adds to the TemporalJobType name to get the appropriate task queue.
Does that make sense? I haven't reviewed this full PR but I want to leave this comment up front to see what you think - I think it will make it easier to use/test/maintain the RouterService and TaskQueueMapper classes, and it forces some level of convention around how we name task queues for different jobs and geographies. Let me know what you think!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, thanks for the suggestion. That's done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! I left some minor nits and suggestions
...ver/src/main/java/io/airbyte/commons/server/scheduler/DefaultSynchronousSchedulerClient.java
Outdated
Show resolved
Hide resolved
...ver/src/main/java/io/airbyte/commons/server/scheduler/DefaultSynchronousSchedulerClient.java
Outdated
Show resolved
Hide resolved
...ver/src/main/java/io/airbyte/commons/server/scheduler/DefaultSynchronousSchedulerClient.java
Outdated
Show resolved
Hide resolved
@@ -1544,6 +1544,14 @@ public Geography getGeographyForConnection(final UUID connectionId) throws IOExc | |||
.fetchOneInto(Geography.class); | |||
} | |||
|
|||
public Geography getGeographyForWorkspace(final UUID workspaceId) throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this used in this PR, is it called in a different PR or in Cloud? Also probably worth adding a quick unit test for this method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - going to be, because at the stage of discover/check we will only have workspace Id available to query which region we should use. Will add a test.
airbyte-workers/src/main/java/io/airbyte/workers/ApplicationInitializer.java
Show resolved
Hide resolved
airbyte-workers/src/main/java/io/airbyte/workers/ApplicationInitializer.java
Show resolved
Hide resolved
Mockito.when(mTaskQueueMapper.getTaskQueue(Geography.EU)).thenReturn(EU_TASK_QUEUE); | ||
Mockito.when(mTaskQueueMapper.getTaskQueue(Geography.AUTO, TemporalJobType.SYNC)).thenReturn(US_TASK_QUEUE); | ||
Mockito.when(mTaskQueueMapper.getTaskQueue(Geography.US, TemporalJobType.SYNC)).thenReturn(US_TASK_QUEUE); | ||
Mockito.when(mTaskQueueMapper.getTaskQueue(Geography.EU, TemporalJobType.SYNC)).thenReturn(EU_TASK_QUEUE); | ||
} | ||
|
||
@Test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could turn this into a @ParameterizedTest where it takes in an @EnumSource for TemporalJobType
and verifies that it works correctly for everything, instead of just SYNC. Here's an example test that uses an EnumSource: https://github.com/airbytehq/airbyte-platform-internal/blob/42ac3ae31fb7a3ce16862597c637ff63e8c307f1/cloud-config/cloud-config-persistence/src/test/java/io/airbyte/cloud/config/persistence/billing/BillingPersistenceTest.java#L201-L225
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess problem is we are not doing routing logic for all TemporalJobType enums.
I think testing sync only at RouterServiceTest is fine - the other tests can be tested within taskQueueMapper logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, the @EnumSource takes in a list of the values you want to test: https://www.baeldung.com/parameterized-tests-junit-5#3-enum
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But yeah, not critical to cover everything here, I'm mostly just trying to spread awareness of ParameterizedTest because of how useful it is!
What
Check and discover workflow will now use a routing logic to decide which task queue to enqueue the job.
#21291
How
Expanding routeService to support check/discover.
Inject routeService to server app.
Recommended reading order
Two major parts I want this to get a closer look:
taskQueueMapper
in cloud, is it okay for me to inject it as a parameter?🚨 User Impact 🚨
Are there any breaking changes? What is the end result perceived by the user? If yes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.
No - changes should be invisible to user.
Tested with https://github.com/airbytehq/airbyte-cloud/pull/4185