Improve log limits UX : select log end & raised limit #97
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issues #88 & #89 showcase bad UX of the current log query limit.
Grafana's pagination components may fail up to v10.3, v10.4 should fix issues with the "older logs" button not working
-> Won't fix, wait for next release, maybe document the issue ?
Timestamp resolution matters, as grafana paginates on timestamp only and at the moment doesn't provide any hint about the data already fetched when issuing a page query. Too many records with the same timestamp will cause data to be skipped between pages. If this issue arises, using a finer timestamp resolution and raised query limits are the solution.
-> Raise default query limits to 1000, partially fixes Make sure older logs can be explored #88 ?
Chronological exploration of logs is a use case where the limit can cause frustration, because the current behavior only returns the log tail.
-> Add a query setting to allow querying the log head (within the defined time range), fixes Add sort direction #89
Bonus refactoring
QueryEditorSpecialMetricRow and QueryEditorRow shared the same layout code, rename and refactor.