feat: Add timestamps to artifacts and worker_metadata for easier tracking#210
feat: Add timestamps to artifacts and worker_metadata for easier tracking#210gasperzgonec wants to merge 19 commits into
Conversation
Started returning `progress_data` in `worker_metadata`.
41866b6 to
4d92e8d
Compare
8c1d0fa to
34d5fec
Compare
radovanjorgic
left a comment
There was a problem hiding this comment.
Looks good, will approve once it is tested and verified by @gasperzgonec and @GasperSenk.
Resolve version conflicts by keeping branch beta version (1.19.9-beta.1) while incorporating main's dependency updates. Co-authored-by: Cursor <cursoragent@cursor.com>
|
|
|
|
0c6068a to
4b27ca8
Compare
|
| }, | ||
| worker_metadata: { | ||
| ...worker_metadata, | ||
| newest_state_date: event.payload.event_context.extract_to, |
There was a problem hiding this comment.
Would it make sense to name these two values extract_from and extract_to or event_context_extract_from and ..._to just to be a bit more consistent? We started using 3 or 4 names for the similar value: last successful sync started, worker oldest/newest, extraction_start/end_time, extract_from/to and now also oldest/newest_state_date. It is really becoming hard to track what is what.
There was a problem hiding this comment.
Also why we need these values here in worker_metadata if we can get it from the event context?
There was a problem hiding this comment.
These worker_metadata fields are meant to be handled in the snapin-manager, and they should be formatted in a way that it can parse it.
I don't think snapin-manager can read from the event_context when we respond, and we just package content in there for the later processing on the platform.
Names have been set to what the platform expects.
Description
This PR merges PRs #202 and #205 together
Connected Issues
Checklist
npm run testOR no tests needed.npm run test:backwards-compatibility.npm run lint.