[GOBBLIN-1453] Improve error reporting on failed flow compilations and fix bugs wher…#3291
[GOBBLIN-1453] Improve error reporting on failed flow compilations and fix bugs wher…#3291Will-Lo wants to merge 4 commits intoapache:masterfrom
Conversation
|
@jack-moseley @arjun4084346 @aplex @umustafi Please take a look |
Codecov Report
@@ Coverage Diff @@
## master #3291 +/- ##
============================================
- Coverage 46.53% 8.99% -37.55%
+ Complexity 10031 1742 -8289
============================================
Files 2037 2037
Lines 79278 79295 +17
Branches 8841 8840 -1
============================================
- Hits 36894 7134 -29760
- Misses 38959 71458 +32499
+ Partials 3425 703 -2722
Continue to review full report at Codecov.
|
gobblin-service/src/main/java/org/apache/gobblin/service/modules/flow/MultiHopFlowCompiler.java
Show resolved
Hide resolved
...e/src/main/java/org/apache/gobblin/service/modules/scheduler/GobblinServiceJobScheduler.java
Show resolved
Hide resolved
gobblin-runtime/src/main/java/org/apache/gobblin/runtime/spec_catalog/FlowCatalog.java
Show resolved
Hide resolved
| } | ||
| // If flow fails compilation, the result will have a non-empty string with the error | ||
| for (Map.Entry<SpecCatalogListener, CallbackResult<AddSpecResponse>> entry : response.getValue().getSuccesses().entrySet()) { | ||
| responseMap.put(entry.getKey().getName(), entry.getValue().getResult()); |
There was a problem hiding this comment.
Please help me understand how the listeners work here. When a listener decides that compilation passes, it sends a Dag, it compilation fails, it returns null. In both the cases will the response be a success? What I mean is do we need to look at response.getValue().getFailures() in any case?
There was a problem hiding this comment.
We do not need to look at response.getValue().getFailures() as long as no uncaught exceptions occur. It might be better if we set the default response from the listener to be a failure, so I'll go ahead and make those changes. So in the following scenarios:
- If flow compilation from the listener is successful, return a dag in the AddSpecResponse
- If flow compilation from the listener is unsuccessful, return null.
- If flow compilation from the listener cannot be found, response should be null.
I think (3) is what caused an error with saving uncompilable flow specs before.
Or we throw an exception on every compilation error that occurs, that can work too. Except that the template resolution exceptions for flow edges can be unrelated to flow so those shouldn't be thrown.
…e failed flow compilations can be saved
a6d7b97 to
809f775
Compare
umustafi
left a comment
There was a problem hiding this comment.
LGTM except for the other tests that are failing. They look like they mostly have to do with missing configs in the spec store (perhaps because of the change in behavior for bad specs)?
a656297 to
85baab3
Compare
85baab3 to
3cba393
Compare
|
+1 LGTM |
|
@sv2000 Could you review/merge? |
…d fix bugs wher… Closes apache#3291 from Will-Lo/modify-flow-compilation- error-reporting
…e failed flow compilations can be saved
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):
Flowconfigs that fail to compile and return 400 errors should report why
Fix bug where templates that fail to compile would reject flow configs (even if they are not relevant)
Tests
Commits