Repository navigation
Conversation
pipeline_core stamps context.timer_start with time.time() and the JOB DONE line (plus the Prefect duration_seconds) subtract it from time.time(). DownloadStage reassigned the same field to perf_counter() to time the fetch, so every job reported an elapsed time of roughly the Unix epoch. Use a local perf_counter start for the fetch log line and leave context.timer_start alone. Regression test asserts the stamp survives the stage and the total elapsed stays in seconds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Member
Author
|
The failing unit and integration checks here die on |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 4 |
| Duplication | 0 |
AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.
TIP This summary will be updated as you push new changes.
There was a problem hiding this comment.
Pull Request Overview
✅ No blocking issues noticed
No blocking findings were identified.
Test suggestions
- A successful download preserves context.timer_start.
- Elapsed time calculated after the download is a realistic duration rather than an epoch-scale value.
- The fetch-completion log uses the local fetch timer and reports the expected duration.
- Timer preservation is verified when deduplication causes an early return.
- Final duration behavior is verified through the local runner and Prefect duration readers.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. The fetch-completion log uses the local fetch timer and reports the expected duration.
2. Timer preservation is verified when deduplication causes an early return.
3. Final duration behavior is verified through the local runner and Prefect duration readers.
TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #355
Proposed fixes:
Every successful job ended with
DATAPUSHER+ v3.0.0a0 JOB DONE! Total elapsed time: 1,792,617,918.06 seconds.for a two second job, and the Prefect path reported the same value asduration_seconds.pipeline_corestampscontext.timer_startwithtime.time(), andlocal_runner._log_doneplus five places inprefect_flow.pysubtract it fromtime.time().DownloadStage.processreassigned the same field totime.perf_counter()to time the fetch and never restored it, so the final subtraction was roughly the Unix epoch.The download stage now keeps a local
fetch_startfor its "Fetched ... in N seconds" line and leavescontext.timer_startalone. The readers are unchanged.pytest tests/test_issue_355_elapsed_time.pybefore the fixpytest tests/test_issue_355_elapsed_time.pyafter the fixpytest tests --ignore=tests/integration --ignore=tests/js(with--ckan-ini)flake8 --extend-ignore=E501ondownload.pyand the test fileProcessingContext. A local variable is enough; the fetch duration is only used for the log line in the same method.prefect_flow.pyand the one inlocal_runner.pyare untouched. They were computing the right thing against a wrong start value.🤖 Generated with Claude Code