Repository navigation
Move the Dag file processor's shared plumbing into a base class - #74040
Merged
Merged
Conversation
This was referenced Oct 1, 2026
jason810496
added this pull request to stack #74044
October 1, 2026 15:18
jason810496
requested review from
guan404ming,
henry3260,
pierrejeambrun and
uranusjr
October 1, 2026 16:50
jason810496
marked this pull request as ready for review
October 1, 2026 16:50
jason810496
requested review from
ephraimbuddy and
jedcunningham
as code owners
October 1, 2026 16:50
jason810496
force-pushed
the
jason/lang-sdk-e2e/03a-dag-processor-base
branch
from
October 2, 2026 00:53
cef0df5 to
0b47cba
Compare
jason810496
force-pushed
the
jason/lang-sdk-e2e/03a-dag-processor-base
branch
from
October 2, 2026 04:07
0b47cba to
3ff4e27
Compare
jason810496
force-pushed
the
jason/lang-sdk-e2e/03a-dag-processor-base
branch
from
October 2, 2026 05:44
3ff4e27 to
0649a43
Compare
Base automatically changed from
jason/lang-sdk-e2e/02b-shared-dag-cycle-detection
to
main
October 2, 2026 09:00
pierrejeambrun
force-pushed
the
jason/lang-sdk-e2e/03a-dag-processor-base
branch
from
October 2, 2026 09:00
0649a43 to
7c112fe
Compare
1 task done
jason810496
force-pushed
the
jason/lang-sdk-e2e/03a-dag-processor-base
branch
from
October 2, 2026 11:41
7c112fe to
ca0d732
Compare
pierrejeambrun
approved these changes
Oct 2, 2026
pierrejeambrun
left a comment
Member
There was a problem hiding this comment.
LGTM, just one suggestion.
BaseDagFileProcessorProcess holds the parse log forwarding, the request handlers, readiness and cleanup. DagFileProcessorProcess keeps only how the Python parse child starts. No behavior change.
The manager gives DagFileProcessorProcess the per-file parse log handle, and the base closes it, as on main. Co-Authored-By: Claude <noreply@anthropic.com>
jason810496
force-pushed
the
jason/lang-sdk-e2e/03a-dag-processor-base
branch
from
October 2, 2026 14:07
ca0d732 to
9024fcd
Compare
This was referenced Oct 5, 2026
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.
Stack (bottom to top): #74034, #74040, #74041, #74042, #74035, #74043, #74036, #74037, #73841, #73845, #73846, #73847
Why
A native Lang-SDK Dag file is parsed by a different child process than a Python Dag file (#74035). Both need the same plumbing for the Dag processor manager.
What changes
No behavior change.
DagFileProcessorProcessis split into a newBaseDagFileProcessorProcess, which holds what any parse child needs: the parse log, the requests answered with the API client, the parse result and the readiness check.DagFileProcessorProcesskeeps the Python-specific start and callbacks. Each class declares its own_request_handlers, typed with itself, from the base's_common_request_handlers.Was generative AI tooling used to co-author this PR?