Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve mapped task group arguments in task worker #27678

Closed

Conversation

uranusjr
Copy link
Member

Depends on #27491. There’s a lot going on here, I’ll split things up after that other PR is merged.

This involves a few things:

* The mapped task group needs to implement parse-time and run-time ti
  count accessors, similar to the mapped operator.
* Since a non-mapped operator can be in a mapped task group and thus
  needs to be expanded, the parse-time and run-time ti count accessors
  are "raised" from MappedOperator to AbstractOperator (so they can be
  used by BaseOperator). These now also considers an operator's parent
  task groups.
* If a ti count accessor is called on a non-mapped operator that's not
  in any mapped task group, the accessor should return a special value
  of a sort. Since None is already used, we raise an exception in this
  case instead (simply called NotMapped). For consistency, the previous
  case where None was returned (upstreams not available) is also changed
  to raise an exception instead (reusing NotFullyPopulated). This means
  the ti count accessors now always return an int, and raise an
  exception whenever the count is not available.
* All of the above result in a coherant interface in AbstractOperator
  that can be used in DagRun to perform ti count revision.

I also removed caching from get_mapped_ti_count since (judging from the
various cache-clearing calls) it seems to be cause more trouble than
benefits.
This is relatively simple in concept, mostly just involving moving
things around and minor refactoring so ti expansion now works for both
MappedOperator (already does) and BaseOperator in a MappedTaskGroup.
This includes everything. I'll probably split this up after the
scheduler part is merged since there's a lot going on here.
@uranusjr
Copy link
Member Author

Everything here is split out into separate PRs. (See references above.)

@uranusjr uranusjr closed this Nov 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant