UI and http end point returns too many history queries

[Sartan4455]

select version();
 _col0 
-------
 465   

Linux centos 7.

The UI and HTTP API end point (/v1/query) is not respecting the history setting.
At least not when using the jdbc driver but also seems to return too many queries in general.

We ran a query too fast(100s per second) via a jdbc driver . It was a fast query (sub 20 ms)

SELECT TABLE_CAT, TABLE_SCHEM, TABLE_NAME, TABLE_TYPE, REMARKS,
TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, REF_GENERATION
FROM system.jdbc.tables
WHERE TABLE_CAT = 'iceberg' AND TABLE_SCHEM LIKE 'sa' ESCAPE '' AND TABLE_NAME LIKE '%' ESCAPE '' AND TABLE_TYPE IN ('TABLE')
ORDER BY TABLE_TYPE, TABLE_CAT, TABLE_SCHEM, TABLE_NAME

It's a bug on our side but it brought out this issue.

When hitting /v1/query or looking at the trino UI I am getting back 28 K (thousand!) finished queries.

$results = queryApi('/v1/query');
count($results)
23840

This brings the trino UI to a halt and taxes my own code when looking at /v1/query

1.) This needs to be fix and respect the max_history setting of 100(default). We do not set this, assuming the default is in place. I misunderstood the config option but this still causes and issue - see extra comment.
2.) The query endpoint could use a limit=x or a sort=asc, desc

Side note: is there a way to get the same data through a normal trino query?

[Sartan4455]

I reread the docs, and it seems I mis understood. It reads more that the max-history is only cleared after the min-expired.
This still causes the trino UI issues(and the /v1/query endpoint issues) if there are a lot of queries in a short period of time. This includes crashing browser tabs.
A limiter to the endpoint request still seems like a relevant idea.