Throw proper exception when multi-instance collection variable is null or is no Collection about camunda-bpm-platform HOT 10 OPEN

This comment was imported from JIRA and written by user JLqwd

Hello, I would like to practice more java and it would be nice if I can try to fix this issue.

from camunda-bpm-platform.

This comment was imported from JIRA and written by user @ThorbenLindhauer

Hi Alexander,

Thanks for your interest in fixing a bug.

We're currently attempting to refactor the multi-instance implementation (not sure if we suceed yet ;), so I think we should tackle this issue after that.
Unfortunately, this is the only ticket labeled EasyPick at the moment. I'll ask my colleagues if we have another easy pick issue that you could work on and get back to you.

Cheers,
Thorben

from camunda-bpm-platform.

This comment was imported from JIRA and written by user JLqwd

Thanks, I will wait or investigate some of the next CAM-3337, CAM-3325, CAM-3251, CAM-3260, CAM-2716, CAM-3236.

Actually I corrected code for current issue before writing comment here, but didn't write unit tests. Don't know if you need it because I couldn't find any tests where ProcessEngineException is checked.

from camunda-bpm-platform.

This comment was imported from JIRA and written by user @ThorbenLindhauer

Hi Alexander,

I'd recommend any of these since they do not require too deep knowledge of the engine internals: CAM-3325 CAM-3260 CAM-2716 CAM-3352

If you want to work on any of these, please comment in the ticket that you are going to provide a pull request. If you've got questions on the issues, feel free to ask them there as well.

Also, please always write test cases. An example for a test case that asserts the presence of an exception can be found here: https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/test/java/org/camunda/bpm/engine/test/api/task/TaskQueryTest.java#L98

Cheers,
Thorben

from camunda-bpm-platform.

This comment was imported from JIRA and written by user Z3azBWy

Is this stil relevant ? I would like to start contributing and I see only three issues with Easypick label. The link on Github towards a JQL query with the issues doesn't work https://github.com/camunda/camunda-bpm-platform/blob/master/CONTRIBUTING.md

from camunda-bpm-platform.

This comment was imported from JIRA and written by user @ThorbenLindhauer

Hey Edmondo,

It's great that you would like to contribute. Currently we use the EasyPick label mostly ourselves for easy tasks that we can commit to without involving product management.

Is there a particular area of the product you would like to contribute to? I can check for open issues that would make for a good first contribution.

Best regards,
Thorben

from camunda-bpm-platform.

This comment was imported from JIRA and written by user Z3azBWy

That's what I can bring on the table:

• core java
• multithreading
• kubernetes and docker

Happy to do anything that can involve some React too, I'd like to learn that. In terms of areas though, the core process engine would be my favourite :)

One think I feel could be improved (at least in my understanding) is how the HistoryService works. What happens if you run certain historical query on a process engine where the history level won't store the data you need?  Do you get empty resuls?

from camunda-bpm-platform.

This comment was imported from JIRA and written by user @ThorbenLindhauer

Hey Edmondo,

Great, here are some tickets that I think are well suited for a first contribution:

• CAM-3356
• CAM-10831
• CAM-10989
• CAM-11328

I'm afraid we're currently not using React in the Camunda BPM product, so I can't offer that :)

{quote}
One think I feel could be improved (at least in my understanding) is how the HistoryService works. What happens if you run certain historical query on a process engine where the history level won't store the data you need? Do you get empty resuls?
{quote}

Yes, this returns empty results in the queries. Let me know if you have an idea for a change, however we must consider that due to our backwards compatibility guarantees (https://docs.camunda.org/manual/7.12/introduction/public-api/#backwards-compatibility-for-public-api) we cannot break existing behavior.

Cheers,
Thorben

from camunda-bpm-platform.

This comment was imported from JIRA and written by user Z3azBWy

I think the current HistoryService can cause subtle business failures to occurs: if you make business decisions based on the content of the history and the history has cleaned, or is not available with the level of detail you expect,  you make the wrong decision. You would better get an exception saying that what you are trying to do is not going to work. 

This is what I suggest:

• Refactoring the HistoryService interface as a composite Interface for the various level of available history type
• Provide a new configuration to the process engine config which is false by default and which we call failFastHistoryService. If this flag is false, nothing changes so there are no binary compatibility concerns
• Implement the HistoryService so that if that flag is enabled, it fails if:
  • The history query looks beyond the beginning of history (we need to add a method to get the beginning of the history)
  • You try to get the subservice (HistoryActivityService ?) whose queries would need a level of history that is not configured for the current process enginee

How does that sound? 

from camunda-bpm-platform.

This comment was imported from JIRA and written by user @ThorbenLindhauer

Hi Edmondo,

I understand your idea and see how it would improve the case you mention. We have to weigh a couple of things though:

• If we have two ways to access history,
  • it will make it more complex for users to do it the "right" way
  • we must maintain and extend both of these access patterns in future Camunda versions

In addition, I think it is not easy to decide if there should be history data for a certain time or not. History time to live is not a central setting, but can be defined for any process definition that is deployed. So for every process definition, history would begin at a different time. However, a query can return data of multiple process definitions.

All in all, I have the impression that this would be a pretty big change (initially and in maintenance) and I'm not sure extending the API in this way is worth the benefit of what we get from it.

That said, the core problem you describe is valid. As you are a support customer, I would recommend to open a support case (feature request) describing the problem and we can work out more solution possibilities with you. I'm afraid my time is limited to discuss complex feature ideas "on the side".

Cheers,
Thorben

from camunda-bpm-platform.