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

Stop traceback when ParsecError occurs during config load on workflow run #4720

Merged
merged 10 commits into from
Mar 31, 2022

Conversation

MetRonnie
Copy link
Member

@MetRonnie MetRonnie commented Feb 28, 2022

These changes close #4216

ParsecErrors that occur during config load (either on workflow start or reload) no longer cause traceback, instead just giving a one line message, because we expect these to occur.

ParsecErrors at any other time during workflow run are unexpected and still give traceback.

Additionally, the Scheduler won't crash if a ParsecError occurs during reload (not sure if this was already fixed, but anyway it is fixed now for sure).

Requirements check-list

  • I have read CONTRIBUTING.md and added my name as a Code Contributor.
  • Contains logically grouped changes (else tidy your branch by rebase).
  • Does not contain off-topic changes (use other PRs for other changes).
  • Applied any dependency changes to both setup.cfg and conda-environment.yml.
  • Appropriate tests are included (integration)
  • Appropriate change log entry included.
  • No documentation update required.

@MetRonnie MetRonnie added the could be better Not exactly a bug, but not ideal. label Feb 28, 2022
@MetRonnie MetRonnie added this to the cylc-8.0rc2 milestone Feb 28, 2022
@MetRonnie MetRonnie self-assigned this Feb 28, 2022
@MetRonnie
Copy link
Member Author

Codecov upload and MacOS tests being particularly flaky today. Tests passing otherwise

Copy link
Member

@wxtim wxtim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall happy

  • Read PR
    • Made a couple of comments about grammar &c, mostly reflecting dissatisfaction with my own previous work!
  • Manually tested as many scenarios as I could think of
  • Run tests locally
  • Looked at testing of this change.
    • I'm a little surprised that this change didn't affect tests/unit/parsec/test_validate.py, but I think it's probably a sign that the tests have been formatted to be robust against small changes to exception messages which I think is a good thing ™.

cylc/flow/parsec/fileparse.py Outdated Show resolved Hide resolved
cylc/flow/parsec/fileparse.py Outdated Show resolved Hide resolved
CHANGES.md Outdated Show resolved Hide resolved
@MetRonnie
Copy link
Member Author

Changes in response to Tim: https://github.com/cylc/cylc-flow/compare/eddf71b0b41a3d71dd1b8ef96fb8729512c2fcfe..5d7e1d9da1c90f7b50bb0c7ad08adf466014f1cd

also viewable by clicking on "force pushed" above where it says

MetRonnie force-pushed the parsec-error-tb branch from eddf71b to 5d7e1d9

finally:
yield caplog
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the logic of moving the yield, feels wrong.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(is it so you can do nasty things like setting up schedulers which are doomed to fail?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Otherwise you won't get the caplog yielded

Copy link
Member Author

@MetRonnie MetRonnie Mar 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you have a good point... this now breaks the teardown if an assertion fails in the test. Converted to draft while I explore a couple of solutions

Note to self: useful info: https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MetRonnie MetRonnie marked this pull request as draft March 2, 2022 22:41
@MetRonnie MetRonnie marked this pull request as ready for review March 3, 2022 12:45
@MetRonnie
Copy link
Member Author

Test failures due to GH Actions flakiness 😒

try:
self.load_flow_file()
except ParsecError as exc:
exc.schd_expected = True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment explaining what the exc.schd_expected is about. Not so keen on the name schd_expected but can't think of anything better.

tests/integration/test_scheduler.py Show resolved Hide resolved
tests/integration/test_scheduler.py Show resolved Hide resolved
tests/integration/test_scheduler.py Outdated Show resolved Hide resolved
@MetRonnie
Copy link
Member Author

Will push up a commit addressing your review comments after your response to my response

@wxtim wxtim self-requested a review March 15, 2022 16:57
Copy link
Member

@oliver-sanders oliver-sanders left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I'm going to try some manual testing, need to consider CylcConfigError too?

@oliver-sanders
Copy link
Member

@MetRonnie waiting on CylcConfigError which should probably be given the same treatment?

#4720 (comment)

@MetRonnie
Copy link
Member Author

MetRonnie commented Mar 31, 2022

CylcConfigErrors are CylcErrors so don't need any special treatment.#

E.g. try out

diff --git a/cylc/flow/config.py b/cylc/flow/config.py
index 44e7b2a6e..7f8054e43 100644
--- a/cylc/flow/config.py
+++ b/cylc/flow/config.py
@@ -1958,6 +1958,8 @@ class WorkflowConfig:
 
     def load_graph(self):
         """Parse and load dependency graph."""
+        from cylc.flow.exceptions import CylcConfigError
+        raise CylcConfigError("Moo")
         LOG.debug("Parsing the dependency graph")
 
         # Generate a map of *task* members of each family.

followed by cylc play

@oliver-sanders
Copy link
Member

CylcConfigErrors are CylcErrors so don't need any special treatment.

Ok, I'll resolve that comment then.

Copy link
Member

@oliver-sanders oliver-sanders left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested, works nicely, couldn't break it 👍.

@MetRonnie
Copy link
Member Author

Ah, I was looking at the wrong comment re: CylcConfigError. Bottom line is:

  • No special treatment is needed during run/restart
  • Special treatment is needed during reload, unless we want to make all CylcErrors "expected" during reload?

Copy link
Member

@wxtim wxtim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy with changes since last I looked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
could be better Not exactly a bug, but not ideal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

config: handle error on config (re)load
3 participants