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

feat: IgnorableAPIError to compliment RetriableAPIError and FatalAPIError #1689

Open
sebastianswms opened this issue May 10, 2023 · 4 comments

Comments

@sebastianswms
Copy link

Feature scope

Taps (catalog, state, stream maps, etc.)

Description

Currently, the validate_response() method in rest.py can throw two types of errors: RetriableAPIError and FatalAPIError. I propose a new type of error in addition to these two: IgnorableAPIError. This error would indicate that:

  • The response being processed is invalid.
  • The endpoint should not be retried.
  • The tap should not fail.
  • The record being processed should be skipped—no data is returned.
  • The tap should continue executing.

If an override of validate_response() was to throw a IgnorableAPIError, the instance would merely be logged and no further action would be taken.

AutoIDM has had multiple use cases for this functionality before when writing taps for applications such as Google Ads or GitLab. In the past, we've done custom implementations, but it seems like something with wide enough applicability that it should be baked into the SDK.

@sebastianswms sebastianswms changed the title feat: SkipAPIError to compliment RetriableAPIError and FatalAPIError feat: IgnorableAPIError to compliment RetriableAPIError and FatalAPIError May 10, 2023
@edgarrmondragon
Copy link
Collaborator

Thanks for logging @sebastianswms! A few folks have requested this (see #280).

Would be willing to contribute it to the SDK?

Copy link

stale bot commented May 9, 2024

This has been marked as stale because it is unassigned, and has not had recent activity. It will be closed after 21 days if no further activity occurs. If this should never go stale, please add the evergreen label, or request that it be added.

@stale stale bot added the stale label May 9, 2024
@edgarrmondragon
Copy link
Collaborator

Still relevant

@stale stale bot removed the stale label May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants