You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the same logic as what is described in #110 and the linked PR, the state bookmarks should use stable IDs for their context, as opposed to the current org / repo:
If a repo is renamed between 2 runs of the tap, the later run would ignore the bookmark, as the repo name would not match anymore. While not a disaster, it would essentially force a full resync of the history of the stream, which is a waste of time/energy/api quotas.
Example of a state bookmark right now:
{
"context": { "org": "scipy", "repo": "scipy" }, // this should use a stable id"replication_key": "updated_at",
"replication_key_value": "2022-05-06T14:29:18Z",
"replication_key_signpost": "2022-06-22T09:07:14.047100+00:00",
"starting_replication_value": "2022-05-06T14:29:18Z",
"progress_markers": {
"Note": "Progress is not resumable if interrupted.",
"replication_key": "updated_at",
"replication_key_value": "2022-06-22T07:55:32Z"
}
},
The text was updated successfully, but these errors were encountered:
Following the same logic as what is described in #110 and the linked PR, the state bookmarks should use stable IDs for their context, as opposed to the current
org / repo
:If a repo is renamed between 2 runs of the tap, the later run would ignore the bookmark, as the repo name would not match anymore. While not a disaster, it would essentially force a full resync of the history of the stream, which is a waste of time/energy/api quotas.
Example of a state bookmark right now:
The text was updated successfully, but these errors were encountered: