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

[GOBBLIN-1969] Increase Visibility for Flow Compilation Failures #3840

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

umustafi
Copy link
Contributor

@umustafi umustafi commented Dec 1, 2023

Dear Gobblin maintainers,

Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!

JIRA

Description

  • Here are some details about my PR, including screenshots (if applicable):
    Empty or null dag execution plans created after compiling do not provide sufficient information as to when and why they occur. 

Tests

  • My PR adds the following unit tests OR does not need testing for this extremely good reason:
    Existing compilation tests work on flow specs manually constructed. Need more insight into why compilation fails on launch to write more useful unit tests.

Commits

  • My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":
    1. Subject is separated from body by a blank line
    2. Subject is limited to 50 characters
    3. Subject does not end with a period
    4. Subject uses the imperative mood ("add", not "adding")
    5. Body wraps at 72 characters
    6. Body explains "what" and "why", not "how"

Copy link
Contributor

@phet phet 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 in general! just a couple of clarifications...

@@ -200,6 +200,12 @@ public void configure(Binder binder) {
ServiceConfigKeys.TOPOLOGYSPEC_FACTORY_KEY, ServiceConfigKeys.DEFAULT_TOPOLOGY_SPEC_FACTORY));
}

// Initialize flow catalog before DagManager is enabled so templates are loaded when initializing the DagManager
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not too familiar w/ Guice... but are you sure the call to binder.bind is guaranteed to synchronously carryout "initializing the flow catalog" (so that finishes before the later call to binder.bind(DagManager.class))?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The order does matter here but this is actually the wrong class initialization and won't fix the problem so leaving out of this PR.

Comment on lines +90 to +91
flowMetadata.get(TimingEvent.FlowEventConstants.FLOW_GROUP_FIELD),
flowMetadata.get(TimingEvent.FlowEventConstants.FLOW_NAME_FIELD));
Copy link
Contributor

@phet phet Dec 4, 2023

Choose a reason for hiding this comment

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

if we do anything other than logging the value, I recommend a default (even when it should always be set). for logging only, it's safe enough to print null, when that's what's actually returned.

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.

2 participants