Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of change
This PR fixes what appears to be a bug from #192.
Here is the stacktrace
Diagnosis
The sync code flow seems to be using
sync_contact_vids
in order to collect a page ofvid
s from the/contacts/v1/lists/all/contacts/all
endpoint.Those get passed off to
_sync_contact_vids
in order to be sent to the/contacts/v1/contact/vids/batch
endpoint to get more details for specificvid
s.The bug seems to be that we assume every object in the first response has a
versionTimestamp
key. So when we initializemodified_time = None
on Line 494, nothing gives it a new value before we trybookmark_values[row['vid']] = utils.strftime(modified_time)
, leading to our stack traceRationale for change
I saw this line in
_sync_contact_vids
which makes me think that we don't always expectbookmark_values
to have thevid
. So the change in this PR is to not convert the a value to a datetime when we don't have a value.Manual QA steps
master
versionTimestamp
. Then it mocks the second response to be super minimal. The actual test is that records in the second response are supplemented with theversionTimestamp
of the first response, if we have it.Risks
versionTimestamp
, it gets attached to the objects in the second response instead of killing the tap.versionTimestamp
is the right choice as a replication key though since it can be null.Rollback steps