apache/dolphinscheduler

Search before asking I had searched in the issues and found no similar feature requirement. Description The API time out as below: http://xx.xx.xx.xx:12345/dolphinscheduler/projects/xxx/task-instances?pageSize=10&pageNo=1&searchVal=&taskCode=&workflowInstanceId=&host=&stateType=&startDate=&endDate=&executorName=&workflowInstanceName= When the number of task instances exceeds a certain threshold, data loading times out (after 10 seconds) upon accessing the task instance page. the SQL of time out I found: SELECT COUNT(*) FROM t_ds_task_instance WHERE project_code = xxx AND task_execute_type = 0; I added an index for table t_ds_task_instance: ALTER TABLE dolphinscheduler.t_ds_task_instance ADD INDEX idx_project_type_submit_time (project_code, task_execute_type, submit_time DESC), ALGORITHM=INPLACE, LOCK=NONE; time out issue fixed. When I continue to search Task Instance data with task instance name or workflow instance name, The timeout issue has cropped up again. The flowing

Search before asking I searched the repository's issues and pull requests and did not find a direct report of the re-login behavior described below. Related reports are linked below. What happened There appears to be an inverted expiry condition in SessionServiceImpl#createSessionIfAbsent in 3.4.3 and the current dev branch. Please confirm whether this is a regression or intentional login policy. The method currently: Refreshes and reuses the existing session when isSessionExpire(session) is true. Deletes the existing session and creates a new session when it is false. However, isSessionExpire returns true when the elapsed time is greater than or equal to the session timeout. This means an unexpired session is invalidated on another successful login, whereas an expired session ID is refreshed and reused. For a user logging in through a second browser/device, the source-level consequence is that the first browser's valid session ID is deleted. This report concerns that behavior and

Search before asking I had searched in the issues and found no similar feature requirement. Description Using NORMAL_JAR or FAT_JAR is very powerful, but it can be a bit cumbersome at times. It would be great if we could support running a snippet of JShell code. Are you willing to submit a PR? Yes I am willing to submit a PR! Code of Conduct I agree to follow this project's Code of Conduct

Search before asking I searched the existing issues and found no issue reporting the same status transition. What happened After a failed task instance is manually set to forced success, its state is correctly changed to FORCED_SUCCESS. If the workflow instance is then recovered using "Recovery Failed": the forced-success task is skipped as expected; downstream tasks continue to run; but the state of the forced-success task instance is changed from FORCED_SUCCESS to SUCCESS. The workflow can continue normally, but the information indicating that the task was completed through manual intervention is lost. The task then appears to have completed successfully through normal execution. This behavior was reproduced on a deployment based on 3.4.2 and was also confirmed in the current dev branch source code. What you expected to happen After recovering the failed workflow: the forced-success task should be treated as successful for dependency and workflow topology evaluation; downstream

Search before asking I had searched in the issues and found no similar issues. What happened When a Dependent task is configured with Dependent Type set to Dependent On Task and Task Name set to ALL, the task fails while processing the dependency result: java.lang.IllegalArgumentException: Invalid key format at org.apache.dolphinscheduler.plugin.task.api.model.DependentItem.fromKey(DependentItem.java:48) at org.apache.dolphinscheduler.server.master.engine.executor.plugin.dependent.DependentTaskTracker.isAllDependentTaskFinished(DependentTaskTracker.java:245) The generated task parameters contain depTaskCode: -1: { "dependentType": "DEPENDENT_ON_TASK", "projectCode": 1001, "definitionCode": 2001, "depTaskCode": -1, "cycle": "day", "dateValue": "today", "parameterPassing": false } In the official dev branch, the UI assigns -1 to the ALL option: taskList.unshift({ value: -1, label: 'ALL', filterLabel: 'ALL' }) DependentItem#getKey() then produces a key simi