Search responds with an additional 500 on Chromium Browser

[JanHoefelmeyer]

Searching on the Chromium Browser will finish and successfully display all results, then shortly afterwards will display a server error. (An error occured on the server. Please contact an administrator.)

The logs read:
level=ERROR msg="database error" err="cannot calculate count timeout: context deadline exceeded"
level=ERROR msg="" request.time=2024-06-19T12:49:01.197Z request.method=GET request.host=localhost:8081 request.path=/api/documents request.query="query=%22RED%20%22%20german%20search%20msg%20as%20&advisories=true&count=1&order=title&limit=10&offset=0&columns=critical%20cvss_v3_score%20cvss_v2_score%20ssvc%20state%20four_cves%20publisher%20title%20tracking_id%20initial_release_date%20current_release_date%20version%20comments%20recent%20versions%20id%20msg" request.params=map[] request.route=/api/documents request.ip=127.0.0.1 request.referer=http://localhost:5173/ request.length=0 response.time=2024-06-19T12:49:31.198Z response.latency=30.001063498s response.status=500 response.length=69 id=8e7e0e68-416c-4eb8-9792-7d6b2089c1a7

[s-l-teichmann]

On the server side this is the expected behavior. By default queries timeout after 30 seconds.

See https://github.com/ISDuBA/ISDuBA/blob/main/docs/isdubad-config.md#section_database max_query_duration.

[s-l-teichmann]

Following this the client should be aware that this can happen and react accordingly.

[ThomasJunk]

To understand better what is happening:

The client sends one request and gets as a response a partial resultset?

And on top the timeout error?

[s-l-teichmann]

Had a look at the HTTP specs. There is no fitting HTTP status code for this, e.g 504 Gateway Timeout has a different meaning. I suggest the client to look at the resulting JSON of the ISE. The value of error should contain context deadline exceeded.

[ThomasJunk]

I want to hint to my question regarding root cause analysis:

When I initiate a search the server either answers with a result set or answers with an error - whatever that may be. But having both seems strange.

[ThomasJunk]

Talked to @s-l-teichmann

This is an interference phenomenon of two things:

• a request is answered with a resultset which is displayed
• a second - longer running but prior - request is answered with a timeout which occurs out of time

Commit adc9c41 should've fixed firing search requests in parallel.

The expected case will now be that a search request is either answered with a result or a timeout. A second search started after the first one should abort the first one so that we end up with consecutive requests.

Open is the task to catch this timeout error and react appropriately.

[ThomasJunk]

In case the search takes too long the error displayed will be The server wasn't able to answer your request in time.. See commit 3cac830

Is this sufficient to close here?

[koplas]

As this is expected behavior and the client correctly displays the timeout message, I will close this issue.