Skip to content
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

Remove additionalProperties: false from all connector specs #14196

Closed
edgao opened this issue Jun 27, 2022 · 14 comments
Closed

Remove additionalProperties: false from all connector specs #14196

edgao opened this issue Jun 27, 2022 · 14 comments
Labels

Comments

@edgao
Copy link
Contributor

edgao commented Jun 27, 2022

As discovered in https://github.com/airbytehq/oncall/issues/289, a spec declaring "additionalProperties": false introduces the risk of accidental breaking changes. Specifically, when removing a property from the spec, existing connector configs will no longer be valid.

We should remove that declaration from all connector specs.

Until this issue is resolved, we should be careful when removing/renaming properties.

@edgao edgao added the area/connectors Connector related issues label Jun 27, 2022
@edgao
Copy link
Contributor Author

edgao commented Jun 27, 2022

@andriikorotkov
Copy link
Contributor

@grishick a similar issue - #14345

@grishick
Copy link
Contributor

grishick commented Jul 6, 2022

@edgao would it make sense to address this connector by connector starting with GA and Beta connectors?

@edgao
Copy link
Contributor Author

edgao commented Jul 7, 2022

probably, yes. I think the ideal ordering is:

  1. Submit a gigantic PR to remove the additionalProperties declaration from ALL connectors spec.json
  2. Submit a PR per connector to publish the image, starting with GA/beta, and maybe not even bothering with alpha at all.

Publishing the image is less urgent/important because it only matters if users downgrade the connector. The "remove property + upgrade" case (i.e. what's described in this issue's description) doesn't require a publish.

@grishick
Copy link
Contributor

grishick commented Jul 7, 2022

@sherifnada are you OK with the approach @edgao suggested?

@sherifnada
Copy link
Contributor

cc @girarda @pedroslopez -- thoughts?

@girarda
Copy link
Contributor

girarda commented Jul 8, 2022

yes - it's safe to set additionalProperties to true.

i think this is a great occasion to try publishing multiple connectors at once

@pedroslopez
Copy link
Contributor

Looks good to me, and good call out from @girarda - we can publish multiple connectors at the same time now so step 2 shouldn't require separate PRs per connector.

I will note that @Phlair recently tried to publish all the java connectors and ran into some issues #13947 - starting with the GA/betas seems fine.

@grishick
Copy link
Contributor

grishick commented Jul 8, 2022

yes - it's safe to set additionalProperties to true.

i think this is a great occasion to try publishing multiple connectors at once

image

@grishick
Copy link
Contributor

grishick commented Jul 8, 2022

A search for additionalProperties": false in spec.json files in connectors/ folder returns 207 results over 100+ connectors. So, I certainly wouldn't want to make 100+ PRs for this change, but I also would like to avoid blocking progress on prioritized connectors (we have 3 PRs waiting for this change). To unblock those other PRs, I will turn this into an Epic and create separate issues for unblocking current progress.

@bazarnov
Copy link
Collaborator

bazarnov commented Jul 27, 2022

We need to add to the assertion the exact place in schema where the additionalProperties should be True but set to false, since now when you debug this, you're blind to see where it should be corrected. Also, we should specify what JSON schema is used (stream schema, spec.json, etc), there is no mention of this. Additionaly, if we have advancedAuth block in spec.json, should we cover this with additionalProperties as well? Please add more explanation from the technical perspective of how this should be properly set up and add more use-cases, not just simple JSON schema with 1 level of nesting. Thanks.

@edgao
Copy link
Contributor Author

edgao commented Aug 2, 2022

@bazarnov could you clarify what you're looking for? This issue is specifically for removing the additionalProperties: false from all connectors' spec.json, not about adding additionalProperties: true anywhere (since by default a schema allows additional properties)

@bazarnov
Copy link
Collaborator

bazarnov commented Aug 2, 2022

Thanks for the question, at present, the value of this setting is obvious, no need to dive into a subject.

For all other future and current validation implementations based on checks of specific properties in schemas or input specifications, it would be nice to have the logging message where the issue occurred and what was expected (if applicable to the case).

Giving the general messages like in this test, not always playing good role for debugging purposes.

lazebnyi added a commit that referenced this issue Aug 8, 2022
* Added parameter 'start_date' in Okta source

added: parameter 'start_date' to source Okta
changed: unit tests

* changes: fix in the case of ISSUE: #14196

* Okta documentation in new format

* changes: fix to use super() instead of instance of stream parent

* changes: additional changes into OKTA documentaton

* changes: switch release to beta

* changed: set dockerImageTag -> 0.1.11

* changed:  source_specs

* ...

* ...

* Rollback releaseStage

* Refactored start date logic

* Deleted microseconds from state

* Add start date to all streams

* Updated to linter

* Fixed unit tests

* Updated unit tests

* auto-bump connector version [ci skip]

Co-authored-by: Serhii <serglazebny@gmail.com>
Co-authored-by: Octavia Squidington III <octavia-squidington-iii@users.noreply.github.com>
marcosmarxm pushed a commit that referenced this issue Sep 9, 2022
* refactor for api layer

* changelog

* Reverts variable name for backwards compatability tests & sets additionalProperties: true in reference to #14196.

* fix: bump dockerfile

* fix: update changelog version to match Dockerfile

* fix: actually update changelog version to match Dockerfile

* auto-bump connector version [ci skip]

Co-authored-by: Nataly Merezhuk <65251165+natalyjazzviolin@users.noreply.github.com>
Co-authored-by: Sajarin <sajarindider@gmail.com>
Co-authored-by: nataly <nataly@airbyte.io>
Co-authored-by: Octavia Squidington III <octavia-squidington-iii@users.noreply.github.com>
robbinhan pushed a commit to robbinhan/airbyte that referenced this issue Sep 29, 2022
* refactor for api layer

* changelog

* Reverts variable name for backwards compatability tests & sets additionalProperties: true in reference to airbytehq#14196.

* fix: bump dockerfile

* fix: update changelog version to match Dockerfile

* fix: actually update changelog version to match Dockerfile

* auto-bump connector version [ci skip]

Co-authored-by: Nataly Merezhuk <65251165+natalyjazzviolin@users.noreply.github.com>
Co-authored-by: Sajarin <sajarindider@gmail.com>
Co-authored-by: nataly <nataly@airbyte.io>
Co-authored-by: Octavia Squidington III <octavia-squidington-iii@users.noreply.github.com>
jhammarstedt pushed a commit to jhammarstedt/airbyte that referenced this issue Oct 31, 2022
* refactor for api layer

* changelog

* Reverts variable name for backwards compatability tests & sets additionalProperties: true in reference to airbytehq#14196.

* fix: bump dockerfile

* fix: update changelog version to match Dockerfile

* fix: actually update changelog version to match Dockerfile

* auto-bump connector version [ci skip]

Co-authored-by: Nataly Merezhuk <65251165+natalyjazzviolin@users.noreply.github.com>
Co-authored-by: Sajarin <sajarindider@gmail.com>
Co-authored-by: nataly <nataly@airbyte.io>
Co-authored-by: Octavia Squidington III <octavia-squidington-iii@users.noreply.github.com>
@girarda girarda added the technical-debt issues to fix code smell label Dec 22, 2022
@evantahler
Copy link
Contributor

I think this epic is able to be closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants