-
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
Expose cron scheduling in the Connections APIs #15253
Conversation
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.
overall lgtm. Added a few comments to the PR.
airbyte-server/src/main/java/io/airbyte/server/handlers/ConnectionsHandler.java
Show resolved
Hide resolved
airbyte-server/src/test/java/io/airbyte/server/helpers/ConnectionHelpers.java
Outdated
Show resolved
Hide resolved
Co-authored-by: terencecho <terence@airbyte.io>
…ionHelpers.java Co-authored-by: terencecho <terence@airbyte.io>
if "cron" in configuration["schedule_data"]: | ||
cron = ConnectionScheduleDataCron(**configuration["schedule_data"]["cron"]) | ||
configuration["schedule_data"]["cron"] = cron | ||
configuration["schedule_data"] = ConnectionScheduleData(**configuration["schedule_data"]) |
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.
is there a reason why the manual type isn't 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.
When the type is manual, then schedule_data
is null, so we only need to handle the schedule_type (in line 606).
Believe any remaining test failures are unrelated to this PR. Adding @alafanechere to take a look at the And @timroes if you want to take a quick look from the API/FE perspective? |
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.
@mfsiega-airbyte I think I made the appropriate changes to the CLI to manage the two new fields schedule_type
and schedule_data
in the generate,
apply
and import
commands. For simplicity, I directly deprecated the schedule
field to encourage CLI users to update their configuration to use these two new fields.
I'm not entirely sure of the logic of the deserialize_raw_configuration
function. This why I "request changes". Could you please let me know if the implementation looks fine?
I also updated the tests so the CLI build should be green.
|
||
if "schedule_type" in configuration: | ||
# If schedule type is manual we do not expect a schedule_data field to be set | ||
# TODO: sending a WebConnectionCreate payload without schedule_data (for manual) fails. |
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.
@mfsiega-airbyte I tried to send a payload with only schedule_type
set to manual
but received an error response saying schedule_data
must be set. Could you please double-check the behavior of this function and if it matches the expected logic on the API side? I'd be thankful if you could also update the corresponding unit test (test__deserialize_raw_configuration
) to ensure all cases are properly handled.
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.
Turns out this was happening when updating from manual -> non-manual; fixed this in the API.
Added a bit of test coverage as well.
Otherwise, LGTM!
Looked at the API (not the implementation). Given that |
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.
LGTM on the octavia-cli side, thanks!
Co-authored-by: Augustin <augustin.lafanechere@gmail.com>
@@ -4564,6 +4634,10 @@ components: | |||
$ref: "#/components/schemas/AirbyteCatalog" | |||
schedule: | |||
$ref: "#/components/schemas/ConnectionSchedule" | |||
scheduleType: |
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.
Why is it not encapsulated in one object?
Schedule:
type:
data:
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.
In my opinion the deeper nesting would make it a bit more unwieldy without too much benefit - encapsulating it under an object doesn't really reduce the cognitive load since every user has to figure out what to do with schedule data anyway whether it's top-level or nested.
I did consider the approach you propose, and I'm not really opposed to it. It comes with the wrinkle that during the migration we have this schedule object that contains both the old and new schemas. (Or - we have some transition period where we have the new schema with some new name, remove the old schema, and then migrate again the new schema to the existing Schedule
name.) All in all this felt simpler; but open to feedback 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.
No strong opinion on my end. However everything related to migration complexity is a non-issue to me since we are v0. I prefer to have something clean that we want than to make design tradoffs based on backward comp or migrations.
What
Expose cron scheduling in the connection APIs.
How
scheduleType
andscheduleData
fields alongside the now-deprecatedschedule
.Recommended reading order
airbyte-api/src/main/openapi/config.yaml
airbyte-server/src/main/java/io/airbyte/server/handlers/ConnectionsHandler.java
airbyte-server/src/main/java/io/airbyte/server/handlers/helpers/ConnectionScheduleHelper.java
airbyte-server/src/test/java/io/airbyte/server/handlers/ConnectionSchedulerHelperTest.java
🚨 User Impact 🚨
None
Pre-merge Checklist
Expand the relevant checklist and delete the others.
Tests
Unit
Integration
Todo in a subsequent PR.
Acceptance
Todo in a subsequent PR.