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

Actually check requires / provides fulfillment #7

Open
jnv opened this issue Oct 26, 2018 · 2 comments
Open

Actually check requires / provides fulfillment #7

jnv opened this issue Oct 26, 2018 · 2 comments
Labels
bug Something isn't working

Comments

@jnv
Copy link
Contributor

jnv commented Oct 26, 2018

I create a data flow with component, which has requires property without any component with corresponding provides. I would expect BakeryJS to check this for me and warn me about missing provides, but instead it happily passes a message without required property:

  name: 'BoxInvocationException',
  jse_shortmsg: 'The box \'wordcount\' in a mapper mode encountered an exception.',
  jse_cause: TypeError: Cannot read property 'split' of undefined

The expected behavior is to check for satisfiability of required properties.

@jnv jnv added the bug Something isn't working label Oct 26, 2018
@jslovan
Copy link
Contributor

jslovan commented Oct 31, 2018

There is a valid reason for running flow with unsatisfied requirements and it is integration testing. Your flow may consist just of the boxes of interest and the unsatisfied requirements would be given as initial value to a job entering the flow.

What about

  • the flow is tested whether it forms connected acyclic graph (every box has an input, no cycles)
  • presence of the required fields is tested in run-time eventually breaking the flow

@jnv
Copy link
Contributor Author

jnv commented Nov 1, 2018

I understand the issue of testing, although I don't think it is in conflict with validation prior to running flow.

I don't know how you can provide an initial input for the component or how do you plan to use that, but from my point of view it is still a part of the graph. Since you receive the initial input with the flow description, you can include it in the validation.

On the other hand, I agree with your proposed solution, I guess it will be simpler. We can also do runtime validation on boxes' output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants