google / google/osdfir-infrastructure
OpenRelik workflow status does not update until browser reload when using latest images
- Dominant language
- Go Template
- Stars
- 213
- Forks
- 30
- Avg merge
- 14h 33m
- Merged PRs (30d)
- 5
Description
### Name and Version
charts/openrelik 2.9.4
### What environment are you using?
None
### What steps will reproduce the bug?
1. Deploy OSDFIR Infrastructure `2.9.4` with OpenRelik enabled.
2. Leave the OpenRelik core image tags at their chart defaults (`latest`).
3. Open OpenRelik in the browser.
4. Create or open a workflow containing a worker, for example the Strings worker.
5. Start the workflow.
6. Observe the worker node in the workflow UI.
### Are you using any custom parameters or values?
_No response_
### What is the expected behavior?
After clicking **Run**, the workflow UI should immediately show the worker as pending/running without requiring a browser reload.
### What do you see instead?
The workflow is submitted successfully, but the frontend does not immediately show the worker as pending/running.
The worker status/spinning indicator only appears after manually reloading the browser window.
The HAR capture shows that the backend is already returning the updated workflow/task state:
- `POST /api/v1/folders//workflows//run/` returns HTTP 200.
- The created task is returned with status `PENDING`.
- The frontend continues polling the workflow endpoint approximately every 3 seconds.
- Subsequent `GET` requests also return the task with `PENDING`.
This suggests that communication between the frontend and API is working, but the frontend does not correctly reconcile/render the new workflow task state.
### Additional information
## Workaround / confirmed fix
Pinning the OpenRelik core components to `0.7.0` resolves the issue:
```yaml
openrelik:
frontend:
image:
tag: "0.7.0"
api:
image:
tag: "0.7.0"
mediator:
image:
tag: "0.7.0"
metrics:
image:
tag: "0.7.0"
```
After redeploying with these versions, the workflow state updates correctly in the frontend without refreshing the browser.
## Possible cause
The OpenRelik Helm chart currently defaults the core components to mutable `latest` tags:
```yaml
frontend:
image:
tag: "latest"
api:
image:
tag: "latest"
mediator:
image:
tag: "latest"
metrics:
image:
tag: "latest"
```
The official OpenRelik installation currently recommends release `0.7.0`, while `latest` is explicitly offered as the bleeding-edge option.
This may result in either:
- a regression in the current OpenRelik `latest` frontend/server images, or
- incompatible versions/builds of the OpenRelik components being pulled at different times.
Because the images use mutable `latest` tags, deployments may also change behavior after a pod restart or image pull without any Helm configuration change.
Contributor guide
Research direction
Start with the Helm chart defaults for the frontend, API, mediator, and metrics image tags, then inspect the frontend workflow polling and state reconciliation described in the report. Reproduce with the chart's latest images, run a workflow, and compare the displayed state with the API responses; done means the pending/running indicator appears without a browser reload.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100