vmui: _time should override the default time range in vmui

[func25]

Is your feature request related to a problem? Please describe

It's not intuitive when specifying _time:10d but only getting 5 minutes of logs due to the default duration set by vmui.

Describe the solution you'd like

It's better to handle _time in one of the following ways:

1. Automatically set the duration in vmui to match the _time value (or the combination of multiple _time values).
2. Throw an error when the client specifies _time. But this isn't ideal, as users would then need to manually select a duration on UI and drop the _time filter.

I’d prefer the backend to have handlers for processing queries from vmui (e.g. detect the correct _time from the query and return it to vmui).

Describe alternatives you've considered

No response

Additional information

No response

[fukawi2]

Agree that this make for a less than optimal UX. I've definitely had users confused by this (including myself until I worked out what was going on!)

Solution 1 sounds ideal, but potentially complex given the large range of supported values to _time. Maybe a short-term solution would be to detect the presence of _time: in the query using JS, and then disable/blur the vmui drop-down? Perhaps a small non-modal pop-up to tell the user "Time selection disabled/ignored because you've added _time: to your query".

Another less elegant solution could be to ditch the drop-down time selector completely and instead default the query box to _time:5m * instead of just *?

[func25]

Hey, we agreed that the _time filter should sync with the top-right textbox. This means when the query contains a _time filter and the frontend executes it, the time selector at the top right will be updated accordingly.

There are two concerns:

1. It may confuse users who explicitly select a fixed time range and then execute a query with another fixed time range filter. The solution would be to add a checkbox in the time range selector to prevent the automatic update of the selected time range.
2. Numerous bugs may occur if the _time filter is extracted and parsed on the web UI side—ideally, this would require a LogsQL parser in JS that must stay in sync with the LogsQL parser on the VictoriaLogs server. The solution is to return the selected time range in the response headers from VictoriaLogs so the web UI can read and apply it properly. For example, it could return a VL-Selected-Time-Range: [start, end] response header.

From my POV, the first option may not be needed, since the query is already more visible and clear to the user’s eyes than the top-right time selector. Adding more options may actually cause more confusion.

It’s better to let the backend handle the LogsQL parsing and return the header so the frontend can update the time range selector accordingly.

[valyala]

Commits a25cfe5 and cea5581 add the VL-Selected-Time-Range http header in responses from /select/logsql/stats_query_range and /select/logsq/hits endpoints. This header contains [start, end] time range obtained from the original query. The start and end values contain unix timestamp in nanoseconds.

@Loori-R , @arturminchukov , please update the built-in web UI, so it reads this header and automatically updates the selected time range if the returned time range in the VL-Selected-Time-Range header doesn't match the selected time range at web UI. It also must automatically re-run the query on the updated time range.

[valyala]

FYI, both commits mentioned above are included in VictoriaLogs v1.30.0. @Loori-R , @arturminchukov , it is time to implement the automatic update of the selected time range at the built-in web UI for VictoriaLogs according to the value returned in the VL-Selected-Time-Range http response header from /select/logsql/stats_query_range function.

[Loori-R]

@valyala, @func25, @fukawi2
What do you think about the following UI behavior?

If the query contains _time:

1. Do not send start / end parameters to requests.

2. Display a non-blocking warning:

   The query contains _time. The time range from the picker is ignored.
   Remove _time to make the time picker range take effect.

Rationale:

• Avoids the current two-step flow (first request with the client time range, then a second request using the VL-Selected-Time-Range).
• Eliminates time synchronization issues between UI and backend.