-
Notifications
You must be signed in to change notification settings - Fork 93
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
Fix hang in graph with absolute point as offset #2088
Fix hang in graph with absolute point as offset #2088
Conversation
@@ -127,6 +127,8 @@ def __str__(self): | |||
# Stringify. | |||
return self.value | |||
|
|||
__repr__ = __str__ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Friendlier display in print
statements.
if target_point == my_point: | ||
# We have found a dependent_point for my_point. | ||
matching_dependent_points.append(dependent_point) | ||
my_cutoff_point = dependent_point |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't see why we need an array when only its last value is used later.
The example suite in #1394 will stall if run as the start task is not retained in the pool. |
Needs a test for ISO8601 absolute points. The following suite fails validation with
|
(Looks like we have discovered even more badness in the code.) |
__SUITE_RC__ | ||
|
||
run_ok "${TEST_NAME_BASE}-datetime" cylc validate 'suite.rc' | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test should actually run the suite to ensure it is working (as opposed to just bypassing a validation issue)
c0ff271
to
508f862
Compare
if not other: | ||
return False | ||
if other is None: | ||
return -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Returning False
would be equivalent to returning 0
- self == other
if other
is None
, etc.
Now running the previously bad suites, instead of just validating them. |
The |
Should all be good now. |
(See also #1773.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of minor questions.
graph = "baz[20200101] => qux" | ||
\end{lstlisting} | ||
\lstset{language=transcript} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should explain why this is BAD, because having a small number of immortal task proxies doesn't seem like it should be so terrible. I presume you mean because iteration across the ever-increasing range of cycle points can become a performance issue? Even so, is it worse in that respect than baz[^] => qux
in a cycling section, which I see quite a lot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is the same as baz[^] => qux
in a cycling section (see #1773). I'll explain the performance issue in the docs for now.
self.cfg['scheduling']['final cycle point']) | ||
except (AttributeError, TypeError): | ||
raise SuiteConfigError( | ||
"ERROR: Invalid recurrence representation: %s" % section) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, do we know for a fact that only bad recurrence expressions cause AttributeError and TypeError here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the statement in the try:
block above, the argument to the get_sequence
function are the section title (which should be a cycle point recurrence), the initial cycle point and the final cycle point.
The initial and final cycle points should already have their syntaxes checked earlier, so the only thing that can cause exception here should be invalid or unsupported recurrence syntax, or a bug in our system.
(tests as working, btw). |
Note this will currently fail for some of the more exotic ISO8601 datetime formats:
|
It should presumably accept the configured |
Maybe even more badness in the date-time parsing logic? |
Can you consult with Ben over morning tea? 😄 |
Actually, I cannot see how any of the above can work.
Note: section header appears to be OK with long format or short format, but not both. For offset, the regular expression appears to only support the short format - as the colon |
I guess those formats were a bit too exotic 😬 |
81122a2
to
91233ac
Compare
I have now added the colon |
Improve cutoff point for absolute offset. * Use stop point of sequence as cutoff point. Improve error message for bad recurrence syntax Allow long date-time format in graph offset. Document performance issue with immortal fixed cycle point tasks.
91233ac
to
7f2762a
Compare
Branch squashed and rebased. |
@oliver-sanders - given all your recent testing etc. of this can you do the review 2 of this please. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The addition of the :
colon to the regex satisfies my ISO8601 concerns.
Looks OK, passes tests.
Improve cutoff point for absolute offset.
Improve error message for bad recurrence syntax
Allow long date-time format in graph offset.
Document performance issue with immortal fixed cycle point tasks.
Fix #1394 (and #1951).