What makes a run “resumable”? I’m having a large ...
# troubleshooting
s
What makes a run “resumable”? I’m having a large initial table sync fail due to a transient connection issues. When I rerun it, it doesn’t seem to pick up where it left off. State file examples in 🧵
When There is a successful run, I get a state that looks like:
Copy code
{
  "singer_state": {
    "bookmarks": {
      "wo_tags": {
        "replication_key": "date_modified",
        "replication_key_value": "2022-08-25T21:04:07Z"
      }
    }
  }
}
But when there is a failure, I get a state that looks like:
Copy code
{
  "error": "Loader failed",
  "singer_state": {
    "bookmarks": {
      "assembly_components": {
        "progress_markers": {
          "Note": "Progress is not resumable if interrupted.",
          "replication_key": "date_modified",
          "replication_key_value": "2022-06-09T17:41:53Z"
        },
        "replication_key_signpost": "2022-08-31T18:11:37.204708+00:00",
        "starting_replication_value": "2000-01-01T00:00:01Z"
      }
    }
  }
}
It looks like the stuff in
progress_markers
would have all the information about the state that would allow it to restart where it left off. Why isn’t that happening? FYI, this is from a tap that I developed using the Meltano SDK, so maybe I missed something?
a
Hi, @sterling_paramore. Can you check if is_sorted is true for the stream(s) in question? Generally speaking, marking your steam at sorted should be sufficient to make it resumable after interruption.
s
I don’t think so….. I just inherited from the base SDK
Stream
class. I didn’t set anything explicitly here. Would that be another
@property
method?
The data does come in sorted, but I didn’t explicitly set any
is_sorted
flag
a
I expect just flagging the stream(s) as sorted should do the trick. You can use the full
@property
syntax but you can also use the shorthand.
Copy code
class SimpleSampleStream(Stream):
    primary_keys = ["id"]
    replication_key = "updated_at"
    is_sorted = True
s
I'll give that a shot. Thanks a ton!
Bah! This still doesn’t seem to be working. I set is_sorted = True, however, it still doesn’t seem to be saving state when I expect it to. I didn’t change
STATE_MSQ_FREQUENCY
, but it doesn’t look like state is getting recorded every 10,000 records. There’s nothing in the log, and if I check the state file manually with
meltano get state
, I just get an empty
{}
well after 10k records.
m
Did you ever solve this @sterling_paramore? Just running into the same problem where the initial sync of the extractor takes a long time and if is interrupted the state db does not contain anything and the sync needs to start over
Changing
STATE_MSQ_FREQUENCY
to
1
will print a lot more
STATE
messages though it doesn't seem to matter, state will only contain the error upon failure
s
I no longer have this problem, but I can’t for the life of me recall how it was resolved. My fault for not updating this thread. Sorry.
m
No worries! Once we figure it out I'll try to remember to update this thread 🙂