Fetch served logs when no remote/executor logs available for non-running task try

[kahlstrm]

This PR implements #32561 in a different way. This caused a regression for our use case, where non-running task try logs weren't shown in UI for running tasks. This is due to us storing the logs on the worker with a Persistent Volume.

Instead of never fetching the logs from the server for non-running task tries, try to fetch them if and only if there are no remote or executor logs available already.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[RNHTTR]

I can't resolve my conversations for some reason... maybe because some git stuff as it's only showing one commit? Either way, my comments were addressed.

[potiuk]

@dstandish ? Can you also take a look maybe?

[dstandish]

@kahlstrm can you clarify what you mean here?

This PR implements #32561 in a different way. This caused a regression for our use case, where non-running task try logs weren't shown in UI for running tasks. This is due to us storing the logs on the worker with a Persistent Volume.

Specifically this part:

This is due to us storing the logs on the worker with a Persistent Volume

What does storing logs on the worker with a PV have to do with anything? If you're storing logs on a PV, shouldn't the webserver have access to it, so it can read the logs directly from the PV?

This PR definitely has introduced a bug, because now users cannot see served logs from triggerer while deferred. But I'm just not sure exactly what functionality here we need to preserve and implement in a different way.

[kahlstrm]

@kahlstrm can you clarify what you mean here?

This PR implements #32561 in a different way. This caused a regression for our use case, where non-running task try logs weren't shown in UI for running tasks. This is due to us storing the logs on the worker with a Persistent Volume.

Specifically this part:

This is due to us storing the logs on the worker with a Persistent Volume

What does storing logs on the worker with a PV have to do with anything? If you're storing logs on a PV, shouldn't the webserver have access to it, so it can read the logs directly from the PV?

This PR definitely has introduced a bug, because now users cannot see served logs from triggerer while deferred. But I'm just not sure exactly what functionality here we need to preserve and implement in a different way.

I'm no longer working with this particular project, but the setup was a PV on the worker that was not mounted on the webserver. When it comes to the bug, I would guess this line change is the culprit for the behavior. The reasoning for that line was to enable fetching previous task instance attempt served logs when there are no remote logs available, but this then introduced the incorrect behavior for the deferred case.

Is TaskInstanceState.DEFERRED always the latest task task instance attempt? If yes, then changing the aforementioned line to the following would perhaps fix this:

if is_in_running_or_deferred and not executor_messages and (not remote_logs or ti.try_number == try_number):

This would efffectively make it act the same as prior to this commit but retain the logic of fetching served logs for previous attempts when no remote logs are available.

This increases the cognitive complexity and readabality a bit, and refactoring the boolean logic as well would be ideal.

[dstandish]

Thanks @kahlstrm, kind of you to follow up. What i'm going with now in #41272 is basically reverting everything -- the fix before yours (that introduced the bug you found), and your two fixes for the bugs introduced by that fix. I am just not sure it's worth the complexity just to avoid an edge case 403 error message that isn't of much consequence.
If someone has time to reintroduce a better approach to suppressing the 403 in that case (e.g. perhaps just suppress the 403) then they can. But for now, I just want to fix the inability to access logs while in deferred state.

[kahlstrm]

Thanks @kahlstrm, kind of you to follow up. What i'm going with now in #41272 is basically reverting everything -- the fix before yours (that introduced the bug you found), and your two fixes for the bugs introduced by that fix. I am just not sure it's worth the complexity just to avoid an edge case 403 error message that isn't of much consequence. If someone has time to reintroduce a better approach to suppressing the 403 in that case (e.g. perhaps just suppress the 403) then they can. But for now, I just want to fix the inability to access logs while in deferred state.

Sounds good to me 👍 I agree with you on this, that adding this amount of logical complexity just to avoid a single request error is not worth it, but didn't myself want to revert the wanted behavior of #32561 immediately. As it now has turned out, having this amount of bugs/unwanted behavior come out of such change is not worth it IMO.