feat: Enhance PodLogs error handling to track stream opening errors

[pasha-codefresh]

…logic to count errors and return the first encountered error if all streams fail when querying previous logs.

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• The title of the PR conforms to the Title of the PR
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green (troubleshooting builds).
• My new feature complies with the feature status guidelines.
• I have added a brief description of why this PR is necessary and/or what this PR solves.
• Optional. My organization is added to USERS.md.
• Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

[qodo-code-review]

Review Summary by Qodo

Enhance PodLogs error handling for stream opening failures

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Track stream opening errors when querying pod logs
• Return first error if all streams fail for previous logs
• Improve error handling for failed pod log stream initialization

Diagram

flowchart LR
  A["Pod Log Query"] --> B["Open Streams"]
  B --> C["Track Errors"]
  C --> D["Count Failures"]
  D --> E{All Streams Failed?}
  E -->|Yes & Previous| F["Return First Error"]
  E -->|No| G["Merge Log Streams"]

Loading

File Changes

1. server/application/application.go Error handling +12/-0

Track and return pod log stream opening errors

• Added streamOpenErrCount and firstStreamOpenErr variables to track stream opening failures
• Implemented error counting logic when GetLogs().Stream() fails for each pod
• Added validation to return the first encountered error if all streams fail when querying previous
 logs
• Error is only returned when GetPrevious() is true and all pod streams fail

server/application/application.go

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Early return leaks goroutines ☑ 🐞 Bug ⛯ Reliability

Description

PodLogs now returns early when all previous-log streams fail, but it has already spawned per-pod
goroutines that send into an unbuffered channel; since mergeLogStreams is never started, those
goroutines block forever and leak. Repeated requests can accumulate stuck goroutines and degrade the
API server.

Code

server/application/application.go[R1897-1902]

  	}()
  }

+	if q.GetPrevious() && streamOpenErrCount == len(pods) && firstStreamOpenErr != nil {
+		return status.Error(codes.InvalidArgument, firstStreamOpenErr.Error())
+	}

Evidence

Each pod spawns a goroutine that, on stream-open error, performs a blocking send to an unbuffered
channel and only then closes it; the newly-added early return exits before mergeLogStreams creates
any reader for those channels, so the send blocks indefinitely and the goroutine never reaches
close().

server/application/application.go[1861-1904]
server/application/logs.go[56-80]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`PodLogs` spawns per-pod goroutines that send an error message into `logStream` (an unbuffered channel). A newly-added early return for the `previous` case can return before any consumer (`mergeLogStreams`) is started, so those goroutines block forever on the channel send.
### Issue Context
This occurs when `q.GetPrevious()` is true and *all* `GetLogs(...).Stream(...)` calls fail.
### Fix Focus Areas
- server/application/application.go[1861-1904]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Previous logs causes UI retry 🐞 Bug ⛯ Reliability

Description

When all previous-log streams fail, PodLogs now returns a gRPC InvalidArgument (HTTP non-200 via
gateway) instead of streaming error lines, and the UI log viewer retries EventSource errors
unconditionally every 500ms. This can result in an infinite retry loop with no user-visible error
and repeated load on the server.

Code

server/application/application.go[R1900-1902]

+	if q.GetPrevious() && streamOpenErrCount == len(pods) && firstStreamOpenErr != nil {
+		return status.Error(codes.InvalidArgument, firstStreamOpenErr.Error())
+	}

Evidence

The server now returns a non-OK response for the previous-logs-all-failed case. The UI’s EventSource
wrapper converts non-200 responses into Observable errors, and PodsLogsViewer’s pipeline only treats
one specific message as non-retryable; for other errors it falls through and then
retryWhen(...delay(500)) keeps retrying indefinitely.

server/application/application.go[1900-1902]
ui/src/app/shared/services/requests.ts[69-83]
ui/src/app/applications/components/pod-logs-viewer/pod-logs-viewer.tsx[155-184]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The server now returns an HTTP non-200 error when previous logs are requested and all pod log streams fail to open. The UI’s log viewer retries EventSource errors unconditionally and does not handle this new error path, potentially causing infinite retries and poor UX.
### Issue Context
`requests.loadEventSource` surfaces non-2xx responses via `observer.error(...)`. `PodsLogsViewer` only stops retrying for the “max pods” message, and otherwise falls through and retries every 500ms.
### Fix Focus Areas
- ui/src/app/applications/components/pod-logs-viewer/pod-logs-viewer.tsx[155-184]
- ui/src/app/shared/services/requests.ts[69-83]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more