By evaluating multiple condition in a separate queue, we serialize their evaluation which avoir races when we compute the outputs for flow triggers.
This is because evaluation is a multi step process: first you get the existing condtion, then you evaluate, then you store the result. As this is not guarded by a lock you must not do it concurrently.
The race can still occurs if muiltiple executors run but this is less probable. A re-implementation would be needed probably in 2.0 for that.
Fixes https://github.com/kestra-io/kestra-ee/issues/4602
This is due to the fact that we now process the execution queue concurrently so there is a race when counting currently running executions. This can be seen easily using a ForEachItem as it could create tens or hundreds of executions almost instantly leading to almost all those executions started as they would all see 0 executions running...
Using a dedicated execution running queue, as done in EE, would serialize the messages and fix the issue.
However, if using multiple executor instances and concurrency limit = 1, there is a theoretical race as no locks will be done if no execution is running. A max surge of executions could be as high as the number of executor but this race is less probable to happen in real world scenario.
Fixes#10167
* fix(filters): change label filtering to 'and' instead of 'or'
link to #8489
* test(execution): add test to validate and behavior
* test(execution): fix test
We usually fail fast, but when a DataException is thrown it means the JDBC driver throws an exception with error code 22: data exception.
As the exception is from the data not the database or the network, there is no point of failfast, we throw a QueueException that may or may not be handled gracefully by the call site.
New search with operation for all /search endpoints :
- define list of operation and fields.
- Add custom parser for filter[field][operation]=value format
- create new Annotation @QueryFilterFormat to bind to specfic pojo
- Implement new abstract repo search method
* WIP: commit to be edited
* feat(*): finished implementation for custom dashboard in JDBC
* chore: disable metricRepository all() test because of leap year
* chore(): PR review
Add date inside the index to speed up order by in case there are a lot of execution queued.
Skip locked records when selecting them as if there is a locked records it means you need to pop the next one.
This would avoid having default values set in the Flow object (JSON) representation so allows to set default that override the object default value (like the one from Lombok `@Builder.Default`).
Fixes#2260Fixes#2797
Allow to set a limit in size for messages, when exceeded, the message will be refused by the Queue.
The JDBC executor and worker has been updated to handle a too big message and fail the execution.
