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

sync branch from main #8

Closed
wants to merge 46 commits into from
Closed

sync branch from main #8

wants to merge 46 commits into from

Conversation

v1r3n
Copy link
Collaborator

@v1r3n v1r3n commented Dec 17, 2023

Pull Request type

  • Bugfix
  • Feature
  • Refactoring (no functional changes, no api changes)
  • Build related changes (Please run ./gradlew generateLock saveLock to refresh dependencies)
  • WHOSUSING.md
  • Other (please describe):

NOTE: Please remember to run ./gradlew spotlessApply to fix any format violations.

Changes in this PR

Describe the new behavior from this PR, and why it's needed
Issue #

Alternatives considered

Describe alternative implementation you have considered

Young-Zen and others added 30 commits November 2, 2023 21:08
* remove previous index of event handlers by event if event handler's event gets updated

* run ./gradlew spotlessApply
…(#3836)

Issue Summary:
There's a race condition in the system involving async system tasks and the WorkflowRepairService. For example, when a SUB_WORKFLOW task starts, the WorkflowRepairService sometimes erroneously reinserts the task into the processing queue because it perceives the task as out-of-sync between the ExecutorDAO and the queueDAO. This issue stems from the AsyncSystemTaskExecutor updating a task's status only after it removes it from the queue, creating a window where the WorkflowRepairService can wrongly assess the task state. This leads to duplicate subworkflows/http/… tasks being executed concurrently, which complicates maintaining idempotency of Tasks.

Proposed Solution:
To resolve the issue, it's suggested that the AsyncSystemTaskExecutor should update the status of tasks before removing them from the queue. This should close the window where the WorkflowRepairService can misidentify the task state and prevent unnecessary re-queuing of tasks. An edge case we’ve considered is if the process crashes after the task is updated but before it's removed from the queue. If that happens, the executor will simply remove the task from the queue the next time it runs, thereby not affecting system correctness.

Co-authored-by: Jaim Silva <[email protected]>
* Version updates
* Fix: include monaco sources into bundle
* Optimizing reading from datastore during WorkflowSweeper#sweep
* Added javadoc to decideWithLock method
---------

Co-authored-by: Boyan Georgiev <[email protected]>
Fix Conductor users broken links
…ername for ACL. (#3847)

Co-authored-by: Anup Chatterjee <[email protected]>
* ISICO-15108: javascript validation done on updating w/d

* ISICO-14902: NPE while checking EvaluatorType is fixed

* ISICO-14902: unused variables removed

* ISICO-15108: javascript validation added in the constraint violation part

* ISICO-15108: getExpression() is used for switch javascript code
* Upgrading OSS libraries with known open CVEs

* Updating the protobuf library.

* Resolve the remaining build issues.

---------

Co-authored-by: Scott Carter <[email protected]>
* Enable hosting app in any route, with easy config

* Review Comments
@v1r3n v1r3n closed this Dec 17, 2023
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.