feedback-to-code/mozzarella huggingface dataset:
Repository: kestra-io/kestra
Issue: Namespace selector dropdown is too small
Labels: bug

### Explain the bug

See screencast https://share.descript.com/view/WbDsryfGEjs

![image](https://github.com/kestra-io/kestra/assets/86264395/c2f80a9a-2ffb-4614-8b43-8e3beca008d7)


### Environment Information

- Kestra Version: 0.14
- Operating System and Java Version (if not using Kestra Docker image):


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/ui/src/components/namespace/NamespaceSelect.vue b/ui/src/components/namespace/NamespaceSelect.vue
index aca07afc06..844f383fef 100644
--- a/ui/src/components/namespace/NamespaceSelect.vue
+++ b/ui/src/components/namespace/NamespaceSelect.vue
@@ -1,5 +1,6 @@
 <template>
     <el-select
+        class="fit-text"
         :model-value="value"
         @update:model-value="onInput"
         clearable
diff --git a/ui/src/styles/layout/element-plus-overload.scss b/ui/src/styles/layout/element-plus-overload.scss
index 7c0c020ff1..c5568d0b2d 100644
--- a/ui/src/styles/layout/element-plus-overload.scss
+++ b/ui/src/styles/layout/element-plus-overload.scss
@@ -123,6 +123,9 @@
 
 
 .el-select {
+    &.fit-text .el-select__input {
+        width: fit-content !important;
+    }
     .el-tag {
         color: var(--el-select-input-color);
 


Test patch:
Repository: kestra-io/kestra
Issue: A missing flow or an exception while loading a flow can crash the webserver
Labels: bug
customer-request

### Explain the bug

When there is a missing flow or an exception while loading a flow during the call to the trigger endpoint, it can crash the execution queue thread and exit the webserver.

The following log is with the Kafka runner but this is not specific to this runner.

```
2024-01-29 13:10:39,247 ERROR kakfa-queue_1 .c.u.ThreadUncaughtExceptionHandlers Caught an exception in Thread[kakfa-queue_1,5,main]. Shutting down.
java.lang.IllegalStateException: Unable to find flow 'io.exchange.import.job-posting.connector.inbound.neeva' with revision 16 on execution 1y9RSMPXNOWs2IyKHqAWy5
    at io.kestra.core.repositories.FlowRepositoryInterface.findByExecution(FlowRepositoryInterface.java:34)
    at io.kestra.webserver.controllers.ExecutionController.lambda$trigger$9(ExecutionController.java:510)
    at io.kestra.ee.runner.kafka.KafkaQueue.lambda$receive$1(KafkaQueue.java:153)
    at java.base/java.lang.Iterable.forEach(Unknown Source)
    at io.kestra.ee.runner.kafka.KafkaQueue.lambda$receive$2(KafkaQueue.java:152)
    at io.micrometer.core.instrument.internal.TimedRunnable.run(TimedRunnable.java:49)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.base/java.lang.Thread.run(Unknown Source)
2024-01-29 13:10:39,355 WARN  command-shutdown io.kestra.cli.AbstractCommand Receiving shutdown ! Try to graceful exit
```



### Environment Information

- Kestra Version: 0.14
- Operating System and Java Version (if not using Kestra Docker image):


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java b/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java
index 369f557ccc..9c3d8a9303 100644
--- a/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java
+++ b/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java
@@ -526,12 +526,8 @@ public Execution create(
                     }
 
                     Execution item = either.getLeft();
-                    if (item.getId().equals(current.getId())) {
-                        Flow flow = flowRepository.findByExecution(current);
-
-                        if (this.isStopFollow(flow, item)) {
-                            emitter.success(item);
-                        }
+                    if (item.getId().equals(current.getId()) && this.isStopFollow(found, item)) {
+                        emitter.success(item);
                     }
                 });
 


Test patch:
Repository: kestra-io/kestra
Issue: Download / Import buttons polute HTML body
Labels: bug
quick-win

### Expected Behavior

We should delete the create <a download> link after the click was done:
![image](https://github.com/kestra-io/kestra/assets/37618489/6ed611a4-be11-4b21-a626-041c0e2cc377)


### Actual Behaviour

_No response_

### Steps To Reproduce

_No response_

### Environment Information

- Kestra Version:
- Operating System (OS / Docker / Kubernetes):
- Java Version (If not docker):


### Example flow

_No response_

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/ui/src/components/executions/Logs.vue b/ui/src/components/executions/Logs.vue
index f6195855c7..92fff95b3f 100644
--- a/ui/src/components/executions/Logs.vue
+++ b/ui/src/components/executions/Logs.vue
@@ -57,6 +57,7 @@
     import LogLevelSelector from "../logs/LogLevelSelector.vue";
     import Collapse from "../layout/Collapse.vue";
     import State from "../../utils/state";
+    import Utils from "../../utils/utils";
 
     export default {
         components: {
@@ -100,12 +101,7 @@
                         minLevel: this.level
                     }
                 }).then((response) => {
-                    const url = window.URL.createObjectURL(new Blob([response]));
-                    const link = document.createElement("a");
-                    link.href = url;
-                    link.setAttribute("download", this.downloadName);
-                    document.body.appendChild(link);
-                    link.click();
+                    Utils.downloadUrl(window.URL.createObjectURL(new Blob([response])), this.downloadName);
                 });
             },
             forwardEvent(type, event) {
diff --git a/ui/src/components/executions/TaskRunLine.vue b/ui/src/components/executions/TaskRunLine.vue
index f2baf577d3..bf2c8ae149 100644
--- a/ui/src/components/executions/TaskRunLine.vue
+++ b/ui/src/components/executions/TaskRunLine.vue
@@ -150,6 +150,7 @@
     import _groupBy from "lodash/groupBy";
     import TaskIcon from "@kestra-io/ui-libs/src/components/misc/TaskIcon.vue";
     import Duration from "../layout/Duration.vue";
+    import Utils from "../../utils/utils";
 
     export default {
         components: {
@@ -258,12 +259,7 @@
                     executionId: this.followedExecution.id,
                     params: {...params, taskRunId: currentTaskRunId}
                 }).then((response) => {
-                    const url = window.URL.createObjectURL(new Blob([response]));
-                    const link = document.createElement("a");
-                    link.href = url;
-                    link.setAttribute("download", this.downloadName(currentTaskRunId));
-                    document.body.appendChild(link);
-                    link.click();
+                    Utils.downloadUrl(window.URL.createObjectURL(new Blob([response])), this.downloadName(currentTaskRunId));
                 });
             },
             forwardEvent(type, event) {


Test patch:
Repository: kestra-io/kestra
Issue: Unable to save the default flow without any modification
Labels: bug
quick-win

### Describe the issue

When you create a flow, there is a default flow in the editor.
It is not possible to save it without any modification.

### Environment

- Kestra Version: 0.15-SNAPSHOT
- Operating System (OS/Docker/Kubernetes):
- Java Version (if you don't run kestra in Docker):


Issue comments:
indeed, quite an urgent bug https://share.descript.com/view/cxaYIAZcOAd 

Pull request review comments:

Patch that resolved the issue:
diff --git a/ui/src/components/flows/FlowCreate.vue b/ui/src/components/flows/FlowCreate.vue
index 441a59acc4..c3eaed86df 100644
--- a/ui/src/components/flows/FlowCreate.vue
+++ b/ui/src/components/flows/FlowCreate.vue
@@ -7,6 +7,7 @@
             :is-creating="true"
             :flow-graph="flowGraph"
             :is-read-only="false"
+            :is-dirty="true"
             :total="total"
             :guided-properties="guidedProperties"
             :flow-validation="flowValidation"
diff --git a/ui/src/components/inputs/EditorView.vue b/ui/src/components/inputs/EditorView.vue
index a8edfb0641..8ed89a7601 100644
--- a/ui/src/components/inputs/EditorView.vue
+++ b/ui/src/components/inputs/EditorView.vue
@@ -66,6 +66,10 @@
             type: Boolean,
             default: true
         },
+        isDirty: {
+            type: Boolean,
+            default: false
+        },
         graphOnly: {
             type: Boolean,
             default: false
@@ -164,7 +168,7 @@
     const editorWidthPercentage = ref(localStorage.getItem(editorWidthStorageKey));
     const validationDomElement = ref(null);
     const isLoading = ref(false);
-    const haveChange = ref(false)
+    const haveChange = ref(props.isDirty)
     const flowYaml = ref("")
     const newTrigger = ref(null)
     const isNewTriggerOpen = ref(false)


Test patch:
Repository: kestra-io/kestra
Issue: Export flows functionality returns 404 error
Labels: bug

### Describe the issue

To reproduce, try exporting flows: https://share.descript.com/view/f5NL85fdMp3

### Environment

- Kestra Version: develop

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/ui/src/stores/flow.js b/ui/src/stores/flow.js
index a720986f9f..57482ab2c7 100644
--- a/ui/src/stores/flow.js
+++ b/ui/src/stores/flow.js
@@ -218,7 +218,7 @@ export default {
                 });
         },
         exportFlowByQuery(_, options) {
-            return this.$http.get(`${apiUrl(this)}/flows/export/by-query`, {params: options})
+            return this.$http.get(`${apiUrl(this)}/flows/export/by-query`, {params: options, headers: {"Accept": "application/octet-stream"}})
                 .then(response => {
                     Utils.downloadUrl(response.request.responseURL, "flows.zip");
                 });


Test patch:
Repository: kestra-io/kestra
Issue: [UI] When a task property is not required, the documentation shows a ? instead of a X
Labels: bug

### Describe the issue

When a tas kproperty is not required, the documentation shows a ? instead of a X

For ex for the log task

![image](https://github.com/kestra-io/kestra/assets/1819009/0aaeaeb9-a8a6-464c-8b76-eb44801e7d45)


### Environment

- Kestra Version:
- Operating System (OS/Docker/Kubernetes):
- Java Version (if you don't run kestra in Docker):


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/core/src/main/java/io/kestra/core/docs/AbstractClassDocumentation.java b/core/src/main/java/io/kestra/core/docs/AbstractClassDocumentation.java
index 541cc2a006..3b5260b485 100644
--- a/core/src/main/java/io/kestra/core/docs/AbstractClassDocumentation.java
+++ b/core/src/main/java/io/kestra/core/docs/AbstractClassDocumentation.java
@@ -112,6 +112,8 @@ protected static Map<String, Object> flatten(Map<String, Object> map, List<Strin
             Map<String, Object> finalValue = (Map<String, Object>) current.getValue();
             if (required.contains(current.getKey())) {
                 finalValue.put("$required", true);
+            } else {
+                finalValue.put("$required", false);
             }
 
             result.put(flattenKey(current.getKey(), parentName), finalValue);


Test patch:
diff --git a/cli/src/test/java/io/kestra/cli/commands/plugins/PluginDocCommandTest.java b/cli/src/test/java/io/kestra/cli/commands/plugins/PluginDocCommandTest.java
index 5c2af967b3..d18fd242cb 100644
--- a/cli/src/test/java/io/kestra/cli/commands/plugins/PluginDocCommandTest.java
+++ b/cli/src/test/java/io/kestra/cli/commands/plugins/PluginDocCommandTest.java
@@ -99,7 +99,7 @@ void run() throws IOException, URISyntaxException {
                 ### `example`
                 * **Type:** ==string==
                 * **Dynamic:** ✔️
-                * **Required:** ❓
+                * **Required:** ❌
 
                 > Example interface
                 """));
Repository: kestra-io/kestra
Issue: [UI] The selected editor option is not visible in the light mode
Labels: bug

### Describe the issue

In the light mode, the selected editor option is not visible (potentially just a color issue):

![image](https://github.com/kestra-io/kestra/assets/86264395/9c1ebf09-fc32-4d16-b4bf-a97c2202849e)


https://share.descript.com/view/tl9ebtpPrAK 



### Environment

- Kestra Version:
- Operating System (OS/Docker/Kubernetes):
- Java Version (if you don't run kestra in Docker):


Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/ui/src/components/inputs/SwitchView.vue b/ui/src/components/inputs/SwitchView.vue
index 64d3352c2d..06349ea779 100644
--- a/ui/src/components/inputs/SwitchView.vue
+++ b/ui/src/components/inputs/SwitchView.vue
@@ -59,4 +59,8 @@
             opacity: 1;
         }
     }
+
+    button.el-button--primary {
+        color: var(--bs-primary);
+    }
 </style>


Test patch:
Repository: kestra-io/kestra
Issue: [JDBC] Errors logs widget is long to fetch on the Homepage
Labels: bug
quick-win

### Explain the bug

See https://preview-oss.kestra.io/ui/dashboard

The "Errors logs" widget is long to fetch on the Homepage

### Environment Information

- Kestra Version: 0.13.0-SNAPSHOT
- Operating System and Java Version (if not using Kestra Docker image):


Issue comments:
We can have default time range to 1H instead of 30 days 👍 
Let's wait for some analysis ;) 

But we use 7 days for some pages, we might decide to align this page also.
Locally, it correctly uses the `logs_namespace_flow` index.

As we switch from 30 days to 7 days in other places I advise to do the same here.

For the record the SQL query is:

```sql
select "value" from logs where ("tenant_id" is null and "deleted" = false and (level in ('ERROR'::log_level, 'WARN'::log_level)) and "timestamp" >= cast('2023-09-24 15:30:39.253+02:00' as timestamp with time zone) and "timestamp" <= cast('2023-10-24 15:30:39.253+02:00' as timestamp with time zone)) order by "timestamp" desc fetch next 10 rows only
```

> As we switch from 30 days to 7 days in other places I advise to do the same here.

I was wrong, apparently we use 30 days by default in all dashboards (homepage, flows, executions, namespaces, ...)

Pull request review comments:

Patch that resolved the issue:
diff --git a/jdbc-h2/src/main/resources/migrations/h2/V1_16__log_timestamp_index.sql b/jdbc-h2/src/main/resources/migrations/h2/V1_16__log_timestamp_index.sql
new file mode 100644
index 0000000000..9ade9e9887
--- /dev/null
+++ b/jdbc-h2/src/main/resources/migrations/h2/V1_16__log_timestamp_index.sql
@@ -0,0 +1,1 @@
+CREATE INDEX IF NOT EXISTS logs_timestamp ON logs ("timestamp");
\ No newline at end of file
diff --git a/jdbc-mysql/src/main/resources/migrations/mysql/V1_16__log_timestamp_index.sql b/jdbc-mysql/src/main/resources/migrations/mysql/V1_16__log_timestamp_index.sql
new file mode 100644
index 0000000000..1524f846c1
--- /dev/null
+++ b/jdbc-mysql/src/main/resources/migrations/mysql/V1_16__log_timestamp_index.sql
@@ -0,0 +1,1 @@
+CREATE INDEX ix_timestamp ON logs (`timestamp`);
\ No newline at end of file
diff --git a/jdbc-postgres/src/main/resources/migrations/postgres/V1_16__log_timestamp_index.sql b/jdbc-postgres/src/main/resources/migrations/postgres/V1_16__log_timestamp_index.sql
new file mode 100644
index 0000000000..9ade9e9887
--- /dev/null
+++ b/jdbc-postgres/src/main/resources/migrations/postgres/V1_16__log_timestamp_index.sql
@@ -0,0 +1,1 @@
+CREATE INDEX IF NOT EXISTS logs_timestamp ON logs ("timestamp");
\ No newline at end of file


Test patch:
Repository: kestra-io/kestra
Issue: Follow an execution led to 500 errors if the flow is not found
Labels: bug

When a flow is not found (I know, this should not happen), the follow from execution will throw a 500 error, it should return a proper response to the use. 

Issue comments:

Pull request review comments:
Not a fan of the name of the method.
You can either update findByExecution to return an optional (and impact all usage) or use the findById() in the only place that needs this method. But adding a method in the interface each time you need something slightly different is a code smell.
Is it realy needed?
If so, EE should be updated accordingly.

Patch that resolved the issue:
diff --git a/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java b/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java
index 6b22407e5b..313e3360bb 100644
--- a/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java
+++ b/webserver/src/main/java/io/kestra/webserver/controllers/ExecutionController.java
@@ -58,6 +58,7 @@
 import io.micronaut.http.annotation.Post;
 import io.micronaut.http.annotation.Put;
 import io.micronaut.http.annotation.QueryValue;
+import io.micronaut.http.exceptions.HttpStatusException;
 import io.micronaut.http.multipart.StreamingFileUpload;
 import io.micronaut.http.server.types.files.StreamedFile;
 import io.micronaut.http.sse.Event;
@@ -1003,7 +1004,7 @@ public MutableHttpResponse<?> resumeByIds(
             );
         }
 
-        for(Execution execution : executions) {
+        for (Execution execution : executions) {
             Execution resumeExecution = this.executionService.resume(execution, State.Type.RUNNING);
             this.executionQueue.emit(resumeExecution);
         }
@@ -1107,7 +1108,14 @@ public Flux<Event<Execution>> follow(
                     () -> executionRepository.findById(tenantService.resolveTenant(), executionId).orElse(null),
                     Duration.ofMillis(500)
                 );
-                Flow flow = flowRepository.findByExecution(execution);
+
+                Flow flow;
+                try {
+                    flow = flowRepository.findByExecution(execution);
+                } catch (IllegalStateException e)  {
+                    emitter.error(new HttpStatusException(HttpStatus.NOT_FOUND, "Unable to find the flow for the execution " + executionId));
+                    return;
+                }
 
                 if (this.isStopFollow(flow, execution)) {
                     emitter.next(Event.of(execution).id("end"));
@@ -1273,7 +1281,8 @@ public MutableHttpResponse<?> setLabelsByIds(
         return HttpResponse.ok(BulkResponse.builder().count(executions.size()).build());
     }
 
-    public record SetLabelsByIdsRequest(List<String> executionsId, List<Label> executionLabels) {}
+    public record SetLabelsByIdsRequest(List<String> executionsId, List<Label> executionLabels) {
+    }
 
     @ExecuteOn(TaskExecutors.IO)
     @Post(uri = "/labels/by-query")


Test patch:
Repository: kestra-io/kestra
Issue: Timezone not being apply correctly on nextExecutionDate 
Labels: backend

Using the below example, next date will not be calculated using the timezone

```
id: test-schedule
namespace: company.team
tasks:
  - id: hello
    type: io.kestra.core.tasks.log.Log
    message: Kestra team wishes you a great day! 👋

triggers:
- cron: "12 13 * * *"
  id: schedule_trigger
  timezone: Asia/Kolkata
  type: io.kestra.core.models.triggers.types.Schedule
```

Issue comments:

Pull request review comments:

Patch that resolved the issue:
diff --git a/core/src/main/java/io/kestra/core/models/triggers/types/Schedule.java b/core/src/main/java/io/kestra/core/models/triggers/types/Schedule.java
index 86cd22da83..c1af26cec9 100644
--- a/core/src/main/java/io/kestra/core/models/triggers/types/Schedule.java
+++ b/core/src/main/java/io/kestra/core/models/triggers/types/Schedule.java
@@ -254,12 +254,12 @@ public ZonedDateTime nextEvaluationDate(ConditionContext conditionContext, Optio
             // is after the end, then we calculate again the nextDate
             // based on now()
             if (backfill != null && nextDate != null && nextDate.isAfter(backfill.getEnd())) {
-                nextDate = computeNextEvaluationDate(executionTime, ZonedDateTime.now()).orElse(null);
+                nextDate = computeNextEvaluationDate(executionTime, convertDateTime(ZonedDateTime.now())).orElse(null);
             }
         }
         // no previous present & no backfill or recover missed schedules, just provide now
         else {
-            nextDate = computeNextEvaluationDate(executionTime, ZonedDateTime.now()).orElse(null);
+            nextDate = computeNextEvaluationDate(executionTime, convertDateTime(ZonedDateTime.now())).orElse(null);
         }
 
         // if max delay reached, we calculate a new date except if we are doing a backfill
@@ -280,7 +280,7 @@ public ZonedDateTime nextEvaluationDate(ConditionContext conditionContext, Optio
     public ZonedDateTime nextEvaluationDate() {
         // it didn't take into account the schedule condition, but as they are taken into account inside eval() it's OK.
         ExecutionTime executionTime = this.executionTime();
-        return computeNextEvaluationDate(executionTime, ZonedDateTime.now()).orElse(ZonedDateTime.now());
+        return computeNextEvaluationDate(executionTime, convertDateTime(ZonedDateTime.now())).orElse(convertDateTime(ZonedDateTime.now()));
     }
 
     public ZonedDateTime previousEvaluationDate(ConditionContext conditionContext) {
@@ -301,7 +301,7 @@ public ZonedDateTime previousEvaluationDate(ConditionContext conditionContext) {
                 conditionContext.getRunContext().logger().warn("Unable to evaluate the conditions for the next evaluation date for trigger '{}', conditions will not be evaluated", this.getId());
             }
         }
-        return computePreviousEvaluationDate(executionTime, ZonedDateTime.now()).orElse(ZonedDateTime.now());
+        return computePreviousEvaluationDate(executionTime, convertDateTime(ZonedDateTime.now())).orElse(convertDateTime(ZonedDateTime.now()));
     }
 
     @Override


Test patch:
Repository: kestra-io/kestra
Issue: [UI] Fix how we display default values in the plugin/task docs
Labels: bug
quick-win

### Feature description

E.g. the `batch.rows` separator is read as an empty line

![image](https://github.com/kestra-io/kestra/assets/86264395/93352bec-d7f7-4e71-b4e2-d00068cf7803)

https://kestra.io/plugins/core/tasks/flows/io.kestra.core.tasks.flows.foreachitem

Issue comments:
I'm afraid there is no one-size-fits-all here as we sometime may want to escape some special char to be displayed in the documentation and sometimes not.

In these cases, the best is to add a `defaultValue` in the schema, this will override in the documentation the default value computed from the task default attribute value.

I'll do it for the task referenced here.

Pull request review comments:

Patch that resolved the issue:
diff --git a/core/src/main/java/io/kestra/core/storages/StorageSplitInterface.java b/core/src/main/java/io/kestra/core/storages/StorageSplitInterface.java
index f5a7e26b99..19b2a470d3 100644
--- a/core/src/main/java/io/kestra/core/storages/StorageSplitInterface.java
+++ b/core/src/main/java/io/kestra/core/storages/StorageSplitInterface.java
@@ -50,7 +50,8 @@ public interface StorageSplitInterface {
     Integer getRows();
 
     @Schema(
-        title = "The separator used to split a file into chunks. By default, it's a newline `\\n` character. If you are on Windows, you might want to use `\\r\\n` instead."
+        title = "The separator used to split a file into chunks. By default, it's a newline `\\n` character. If you are on Windows, you might want to use `\\r\\n` instead.",
+        defaultValue = "\\n"
     )
     @PluginProperty
     String getSeparator();


Test patch: