fix: ensure filtered issue listing does not break

[LucasSantos27]

This PR updates the behavior of the issue filtering endpoint.
Previously, when no issues matched the given filters, the API returned a 500 Internal Server Error.
Now, it correctly returns a 200 OK response with a correct response.

Related Issue

• Closes Issue listing breaks on 0 results #1381

How to test it

Using curl

curl -X 'GET' \
  'http://localhost:8000/api/issue/?interval_in_days=120&filter_origin=nonexistent' \
  -H 'accept: application/json'

Or via browser
<local_url>/issues?df|o|nonexistent=true

Expected behavior

• Before (main branch):

Response: 500 Internal Server Error

• After (this PR):
  Response: 200 OK

Body:

{"issues":[],"extras":{},"filters":{"origins":["maestro","redhat"],"culprits":["code","harness","tool"],"categories":[]}}

[MarceloRobert]

I think that it would be best if the endpoint returned the IssueListingResponse as usual, because it will have data there (even if 0 issues are returned)

[LucasSantos27]

I think that it would be best if the endpoint returned the IssueListingResponse as usual, because it will have data there (even if 0 issues are returned)

@MarceloRobert Yeah, you're right. It's better if I process the extra_details when the filtered issues aren't empty.

I've just updated it.

[MarceloRobert]

Interesting that the problem was in assign_issue_trees but assign_issue_first_seen was protected against this problem because it has a if not issue_id_list: return [].

The change you made here is great, but could you also add that condition to assign_issue_trees so that it becomes bulletproof in case someone wants to use just that function?

[MarceloRobert]

Looks good to me

[LucasSantos27]

This PR was already merged via the command line, but it didn’t close automatically, so I closed it manually.