-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
🐛 Source Intercom: backoff for companies' scrolling #8395
🐛 Source Intercom: backoff for companies' scrolling #8395
Conversation
/test connector=connectors/source-intercom
|
airbyte-integrations/connectors/source-intercom/acceptance-test-docker.sh
Show resolved
Hide resolved
airbyte-integrations/connectors/source-intercom/source_intercom/source.py
Outdated
Show resolved
Hide resolved
|
||
return False | ||
|
||
def should_retry(self, response: requests.Response) -> bool: |
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.
if the scroll exists, shouldn't we use it instead? why would we retry the same request if the scroll exists?
Also, if we restart the scroll, wouldn't that re-load all data from scratch? From the docs:
When this occurs you will need to restart your scroll query as it is not possible to continue from a specific point when using scroll.
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.
Every request must add a next token ID for loading of a next page. It will be a new scroll if this token is not set.
Restarting is available after 2 events only:
- all pages are loaded before
- anything didn't load a page within a minute.
Thus working with this scroll endpoint is atomic. I mean at same time only one script(connector etc) can use it. The intercom API will return some another error(code value) and our connector will handle it by default CDK logic if there are some problems with resources or requests. And it will be a failure of sync.
All other connectors(scripts etc) have to wait.
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 see, so scrolls might have been created from external processes. very interesting.
I wonder if this means we should just use the other endpoint by default. Maybe using the scroll endpoint only on the first sync, or if there is an ongoing external scroll, just use the other endpoint by default. It would allow us to offer incremental sync for this endpoint as well by exploiting the sorting of the data.
Maybe the strategy to use here is:
- on the very first sync, use the scroll endpoint. If there is an ongoing scroll, wait until it is done and try to acquire a scroll.
- every other sync use the other endpoint. It is highly unlikely there will be more than 10,000 companies since the previous time the data was read so the limitation of that endpoint will not be relevant.e
WDYT?
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.
@sherifnada ,
This "scroll" endpoints is bottleneck for a part of streams. I propose to implement your second point only with comments:
- load the first page with only one record by the "non-scroll" endpoint (it doesn't have any restrictions).
- read its response value "total_count" and:
2a. use the "non-scroll" endpoint further if total_count <= N (100, 1000, 10^5 ?)
2b. use the "scroll" endpoint if total_count > N
Sure we can add a new spec property for installation of the variable "N". But I understand to it is the bad idea)
…ntercom-companies-sync-failure
/test connector=connectors/source-intercom
|
/test connector=connectors/source-intercom
|
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.
Let's ship this as an immediate fix, but apply the strategy you describe in the comment below. We need to validate though, if there are more than 10k companies, will the total_count
returned from the non-scroll list endpoint contain the correct total number?
/test connector=connectors/source-intercom
|
/publish connector=connectors/source-intercom
|
* backoff for companies scroll * remove a unused companies stream property * fix tests * bump version * update source_specs
What
OnCall issue: https://github.com/airbytehq/oncall/issues/39
Reason:
The Intercom API can provide only one scroll request at same time and every "scroll" request should load all data pages. Creation of a new "scroll" request will be blocked within a minute if a previous request doesn't load all data. More details here.
How
Implementation of a custom backoff case for this error response. The API returns code_status == 400 and a response body includes JSON item "code" with the value
scroll_exists
.Additionally we've fixed another possible bug: The Intercom API supports several versions and its relevant value is managed into accounts' profiles (docs). Not all streams are available for every version.
But we can set a necessary version with an additional header directly.
Both bugs've been covered by tests.
Recommended reading order
integration_test.py
source.py
Pre-merge Checklist
Updating a connector
Community member or Airbyter
airbyte_secret
./gradlew :airbyte-integrations:connectors:<name>:integrationTest
.README.md
bootstrap.md
. See description and examplesdocs/integrations/<source or destination>/<name>.md
including changelog. See changelog exampleAirbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
/test connector=connectors/<name>
command is passing./publish
command described here