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

test(acceptance): add acceptance tests #6

Merged
merged 2 commits into from
Aug 16, 2022
Merged

Conversation

donatorsky
Copy link
Contributor

Description

Add acceptance tests as described here:
ConduitIO/conduit-connector-sdk#14

Quick checks:

  • I have followed the Code Guidelines.
  • There is no other pull request for the same update/change.
  • I have written unit tests.
  • I have made sure that the PR is of reasonable size and can be easily reviewed.

@donatorsky donatorsky self-assigned this Jul 8, 2022
@donatorsky donatorsky force-pushed the test/acceptance-tests branch 4 times, most recently from a39670f to b8cbb4a Compare July 8, 2022 12:05
},

Skip: []string{
// When restarting snapshot position, bucket is read from the beginning
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, only the object metadata is read from the beginning, but the object contents, are not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Object's contents is also read while iterating over storage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And from what we know so far, it's not possible to avoid that? It could be come a bottleneck.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Object's contents is downloaded separately:
https://github.com/miquido/conduit-connector-azure-storage/blob/main/source/iterator/snapshot.go#L118-L123

So you can potentially adjust the logic 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that's a useful reference!

// Cannot be tested. driver.WriteToSource() creates all records at once while CDC position is
// created after the Snapshot iterator finishes iterating. So from the CDC iterator point of view,
// there are no new records available.
"TestAcceptance/TestSource_Open_ResumeAtPositionCDC",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you clarify this a little bit further please? Also, what's the actual error you're getting?

TestSource_Open_ResumeAtPositionCDC is doing the following:

  • opens a source, which has no records in it
  • reads all the records
  • acknowledges half of those
  • restarts the source

Regardless of the internals of a connector, this use case is something which should pass.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lovromazgon also pointed out that these 4 lines should give the source enough time to switch from doing a snapshot (without data) and switch to CDC. The timeout was lower in one of the previous versions of the SDK, so that might have been an issue for you. What he suggested is to upgrade to the latest SDK.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not the matter of time required for connector to switch from the Snapshot iterator to CDC. To make this test working, you would need to change the TestSource_Open_ResumeAtPositionCDC test logic:
obraz

want creates all files in the source and snapshot iterator sees them all. CDC iterator does not see any changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

want creates all files in the source and snapshot iterator sees them all. CDC iterator does not see any changes.

I think here we have the answer. The expectation in this test is that there's an empty snapshot, after which the connector should switch to CDC. i.e. we have:

  1. open source, which has no data in it
  2. start reading -> no data, so no snapshot, and we start listening for changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The important thing to note in that test is that it first tries to read something from the source and expects to get back a context.DeadlineExceeded or sdk.ErrBackoffRetry (see these lines). This means that when the connector first tries to do a snapshot it should discover that there is no data, meaning that the initial snapshot is empty and it should switch to CDC. Any new record that is created after that is considered a change of the existing state and not part of the existing state (existing state is empty).

We need a read timeout because we can't wait forever. The Read method is expected to block until it has a record to return, and there should be no records, so it would block forever. You can adjust the timeout if 5 seconds (default) is not enough to determine that there are no initial records to put into the snapshot.

If you don't think that is correct, I'd be interested to hear what you think should be the criteria for switching from "snapshot" to "CDC"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check for ErrSnapshotIteratorIsStopped is already present in Read method:
https://github.com/miquido/conduit-connector-azure-storage/blob/1dc53a90881cd32092fbd3b92ea34e7b1146eba2/source/source.go#L98-L102

Then converted to ErrBackoffRetry and retried. Ideally would be to update the S3 and this connector logic so that it changes to CDC iterator earlier. I don't think it is in the scope of this PR, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you are saying the scope of this PR is to run acceptance tests and ignore the tests that fail? I would expect the scope to include fixing the issues found by the acceptance tests (unless they are unreasonably big issues). But let's not argue about technicalities, if you want to fix it in a follow-up PR that's fine by me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the test failing because there really is an issue, or is the test itself too general and does not support such a real use case? You will face the same problem for each source that does not support consistent iteration (true cursors/scrolls, instead of "just iterate over the current list of items and ignore the fact it may change over the time of iteration"). You are already facing this problem for S3 and Azure connectors.

This fact is already documented: https://github.com/miquido/conduit-connector-azure-storage/blob/main/README.md?plain=1#L20. IMO, "fixing" this is actually implementing a way of determining which file has already been iterated and skipping it. It definitely falls into "unreasonably big issue" bag, and it deserves a separate work+PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I'm able to understand the connection between this tests failure and the fact that Azure nor S3 support true cursors/scrolls/CDC?

If we take a step back, this test is about using CDC after we are done with the snapshot (be it empty or not). The Azure Storage connector has a CDC mode, so we expect the connector to switch to that mode.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this at a standup. It looks like the best path forward is to accept the acceptance tests as they are, and work on improving the snapshot/CDC behavior separately. The issue is here.

Thanks @lovromazgon @donatorsky for sharing your thoughts!

@donatorsky donatorsky force-pushed the test/acceptance-tests branch 2 times, most recently from 05f7c49 to 7ccc2ce Compare July 28, 2022 09:20
@donatorsky donatorsky merged commit ae680be into main Aug 16, 2022
@donatorsky donatorsky deleted the test/acceptance-tests branch August 16, 2022 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants