Is your feature request related to a problem? Please describe.
When MinIO is disabled and no S3-compatible storage is configured, the TestWorkflow runner retries SaveExecutionLogsPresigned indefinitely, blocking the execution from ever reaching a terminal state. Webhook events (end-testworkflow-success, end-testworkflow-failed) never fire, and the execution status in PostgreSQL stays running forever. This makes webhook-based CI/CD integrations and orchestration tools that poll execution status completely non-functional in environments without object storage.
This is a regression. In 1.x, MinIO was optional — executions finalized through MongoDB regardless of MinIO availability, and execution output was stored inline and accessible in webhook payload templates via {{ .TestExecution.ExecutionResult.Output }}. In 2.6.0, both capabilities are lost when object storage is unavailable.
Describe the solution you'd like
Two related improvements:
-
Make log saving non-blocking. If object storage is unreachable or not configured, the runner should log a warning and allow the execution to proceed to a terminal state. Log persistence failure should be a degraded-but-functional condition, not an execution blocker.
-
Provide an inline output field in the execution record. Test scripts typically emit compact structured output. Storing the last N lines of stdout inline in PostgreSQL alongside the execution record would make it accessible in webhook payload templates — restoring the Output field equivalent from 1.x — without any object storage dependency. Full log archives can continue to use object storage; the inline field is for result payloads and webhook integrations.
Describe alternatives you've considered
-
Fallback log sink — support writing logs to stdout or a mounted PVC when object storage is not configured, decoupling log persistence from the execution lifecycle entirely.
-
Config flag / timeout — expose an option such as logStorage.required: false or a configurable timeout on SaveExecutionLogsPresigned, so operators can opt into non-blocking behavior without changing the default for environments that do have object storage.
Additional context
Version: 2.6.0 (standalone), MinIO disabled, no S3 configured.
Use case: enterprise / air-gapped / policy-constrained environments where MinIO is not approved and external S3 is not reachable, but webhook-based pipeline triggers and structured result reporting are required.
Impact: execution status polling loops hang indefinitely; all end-testworkflow-* webhook events suppressed; webhook-based result reporting to external test management systems broken.
Thank you in advance!
Is your feature request related to a problem? Please describe.
When MinIO is disabled and no S3-compatible storage is configured, the TestWorkflow runner retries SaveExecutionLogsPresigned indefinitely, blocking the execution from ever reaching a terminal state. Webhook events (end-testworkflow-success, end-testworkflow-failed) never fire, and the execution status in PostgreSQL stays running forever. This makes webhook-based CI/CD integrations and orchestration tools that poll execution status completely non-functional in environments without object storage.
This is a regression. In 1.x, MinIO was optional — executions finalized through MongoDB regardless of MinIO availability, and execution output was stored inline and accessible in webhook payload templates via {{ .TestExecution.ExecutionResult.Output }}. In 2.6.0, both capabilities are lost when object storage is unavailable.
Describe the solution you'd like
Two related improvements:
Make log saving non-blocking. If object storage is unreachable or not configured, the runner should log a warning and allow the execution to proceed to a terminal state. Log persistence failure should be a degraded-but-functional condition, not an execution blocker.
Provide an inline output field in the execution record. Test scripts typically emit compact structured output. Storing the last N lines of stdout inline in PostgreSQL alongside the execution record would make it accessible in webhook payload templates — restoring the Output field equivalent from 1.x — without any object storage dependency. Full log archives can continue to use object storage; the inline field is for result payloads and webhook integrations.
Describe alternatives you've considered
Fallback log sink — support writing logs to stdout or a mounted PVC when object storage is not configured, decoupling log persistence from the execution lifecycle entirely.
Config flag / timeout — expose an option such as logStorage.required: false or a configurable timeout on SaveExecutionLogsPresigned, so operators can opt into non-blocking behavior without changing the default for environments that do have object storage.
Additional context
Version: 2.6.0 (standalone), MinIO disabled, no S3 configured.
Use case: enterprise / air-gapped / policy-constrained environments where MinIO is not approved and external S3 is not reachable, but webhook-based pipeline triggers and structured result reporting are required.
Impact: execution status polling loops hang indefinitely; all end-testworkflow-* webhook events suppressed; webhook-based result reporting to external test management systems broken.
Thank you in advance!