-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Disable all broken connections when source is refreshed #20208
Conversation
e8cc8ce
to
fcb37b8
Compare
fcb37b8
to
8432701
Compare
@@ -865,6 +865,20 @@ public List<StandardSync> listWorkspaceStandardSyncs(final UUID workspaceId, fin | |||
return getStandardSyncsFromResult(connectionAndOperationIdsResult); | |||
} | |||
|
|||
public List<StandardSync> listConnectionsBySource(final UUID sourceId, final boolean includeDeleted) 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 just put up a PR with a more complete version of this: https://github.com/airbytehq/airbyte/pull/20264/files#diff-2d29b293778e290157be96e22294c2df1fdfa7c72a48961d03396776446deeddR852
However, my PR might take longer to merge due to breaking UI changes.
connectionStatus = ConnectionStatus.INACTIVE; | ||
} else { | ||
connectionStatus = connectionRead.getStatus(); | ||
final ConnectionReadList connectionsForSource = connectionsHandler.listConnectionsForSource(discoverSchemaRequestBody.getSourceId(), false); |
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 would advocate for avoiding having handlers depend on other handlers. At the handler level, I am currently leaning towards using our DB abstraction directly until we introduce a better layer.
It might be worth checking with the team to agree on a direction moving forward here.
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 interesting, you mean use configPersistence directly instead of going through the connection handler? I may have misunderstood how we wanted to migrate this
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 and I don't think we agreed on a strategy here.
connectionStatus = connectionRead.getStatus(); | ||
} | ||
updateObject.status(connectionStatus); | ||
connectionsHandler.updateConnection(updateObject); |
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.
This feels very broad, from this function, I expect we only modify syncCatalog and the breaking change flag, but this function will actually override the whole object. Should we introduce a more scoped update here?
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.
This is actually a patch update even though the object is named ConnectionUpdate, so it is only modifying the breaking change field and status
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, my point is that if we add other fields to the updateObject
we could end up overriding fields by mistake.
I don't think it is a big issue currently, but this could lead to some surprises.
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 mean adding other fields within this method here? we would only be updating other fields here if we explicitly stated them on the ConnectionUpdate object, but I think that would be expected
updateObject.status(connectionStatus); | ||
connectionsHandler.updateConnection(updateObject); | ||
if (connectionRead.getConnectionId().equals(discoverSchemaRequestBody.getConnectionId())) { | ||
discoveredSchema.catalogDiff(diff).breakingChange(containsBreakingChange).connectionStatus(connectionStatus); |
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.
Can we add some description to the function to highlight that we are modifying the input?
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.
just added a comment where we're calling the function - do you think that works?
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'd say it should be part of the documentation of this function.
updateObject.status(connectionStatus); | ||
connectionsHandler.updateConnection(updateObject); | ||
if (connectionRead.getConnectionId().equals(discoverSchemaRequestBody.getConnectionId())) { | ||
discoveredSchema.catalogDiff(diff).breakingChange(containsBreakingChange).connectionStatus(connectionStatus); |
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'd say it should be part of the documentation of this function.
When one connection's source is refreshed, we want to check each connection that uses that same source and disable them where necessary.
Changes are: