fix(taps): Use recent start_date as starting_replication_value

[ericboucher]

When both a start_date and a replication_start_date are available, I believe that we should take the most recent one.

[codecov]

Codecov Report

Merging #759 (1ccab0a) into main (9dac11c) will increase coverage by 0.04%.
The diff coverage is 100.00%.

❗ Current head 1ccab0a differs from pull request most recent head a6cdfb8. Consider uploading reports for the commit a6cdfb8 to get more accurate results

@@            Coverage Diff             @@
##             main     #759      +/-   ##
==========================================
+ Coverage   80.33%   80.37%   +0.04%     
==========================================
  Files          34       34              
  Lines        3418     3425       +7     
  Branches      679      681       +2     
==========================================
+ Hits         2746     2753       +7     
  Misses        499      499              
  Partials      173      173              

Impacted Files	Coverage Δ
singer_sdk/streams/core.py	81.21% <100.00%> (+0.33%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ericboucher]

@edgarrmondragon I added a check for is_timestamp_replication_key to make it a bit safer and explcit. wdyt?

Since we are in the subcase where a start_date is given as an input, I think this should be enough, but we could also add a try/except around the parsing.

As an alternative, we can indeed make a simple string comparison, although we are not sure what would happen when comparing a uuid and a date from "start_date".

I couldn't find if the format of start_date is actually enforced anywhere.

[edgarrmondragon]

@ericboucher ok, that makes sense and might be good for most use cases. Would you mind adding a test case, perhaps somewhere in

sdk/tests/core/test_streams.py

Line 132 in b0a3c49

def test_stream_starting_timestamp(tap: SimpleTestTap, stream: SimpleTestStream):

?

[ericboucher]

@edgarrmondragon done! Not sure why codecov is not passing though... Any clue? The UI is not very readable... 🤷

[edgarrmondragon]

@ericboucher it seems that codecov doesn't like that there isn't an else branch

I think I have a quick fix for that, and if that works I might push it to this branch 🙂

---

EDIT: Ok so I think that worked. @ericboucher let me know if the changes in d586071 make sense to you

[ericboucher]

@edgarrmondragon your changes make sense to me! Let me know if you any other changes from me :)

feedback addressed and discussed

[edgarrmondragon]

@ericboucher thanks for getting this started! It prompted a useful discussion on our side 😄