Add counts and schema to next queue endpoint

[goldlabelapps]

Refactor queue next route to build a base query/where clause and return richer metadata: fetch the next record, the filtered count, total count, and the queue table schema. Response payload now nests the record alongside filtered_count, total_count, schema and a message, and sets meta status/title accordingly. Also remove unused static asset app/static/python-logo.svg.

[Copilot]

Pull request overview

Refactors the /queue/next route to return richer queue metadata (next record plus counts and schema) alongside the record, and removes an unused static SVG asset.

Changes:

• Refactored /queue/next to build a reusable WHERE clause and return record, filtered_count, total_count, and schema in a nested data payload.
• Updated meta/title/message behavior for “record found” vs “no record” responses.
• Removed app/static/python-logo.svg.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 5 comments.

File	Description
app/api/queue/routes/next.py	Adds filtered/total counts and schema to /queue/next response; refactors query composition.
app/static/python-logo.svg	Removes an unused static asset.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The schema lookup uses information_schema.columns filtered only by table_name = 'queue'. In Postgres this can return columns from multiple schemas if another queue table exists on the DB (and it also makes results depend on search_path). Consider filtering by table_schema (e.g., 'public') and ordering by ordinal_position to make the returned schema deterministic.

Suggested change

	cursor.execute("SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_name = 'queue';")
	cursor.execute(
	"SELECT column_name, data_type, is_nullable "
	"FROM information_schema.columns "
	"WHERE table_schema = 'public' AND table_name = 'queue' "
	"ORDER BY ordinal_position;"
	)

[Copilot]

is_nullable from information_schema.columns is returned as 'YES'/'NO', but the response field is named nullable, which reads like a boolean. Consider either converting this to a boolean (True/False) or renaming the field to something like is_nullable to match the underlying value and avoid surprising API consumers.

Suggested change

	{"name": row[0], "type": row[1], "nullable": row[2]} for row in cursor.fetchall()
	{"name": row[0], "type": row[1], "nullable": row[2] == "YES"} for row in cursor.fetchall()

[Copilot]

This endpoint now runs 4 separate DB queries on every request (next record, filtered count, total count, schema). The two COUNT(*) queries can be combined into a single query (e.g., using subqueries or FILTER), and the schema query is a good candidate for caching since table schemas rarely change at runtime. Without this, /queue/next could become noticeably slower on large tables/high traffic.

[Copilot]

/queue/next appears to be unauthenticated, and the response now includes full table schema details. If this API is exposed beyond trusted/internal users, this increases information disclosure risk. Consider protecting this route (e.g., API key dependency like other DB/LLM routes) or gating/removing schema from the default response.

[Copilot]

There are existing FastAPI endpoint tests for /queue (tests/test_queue.py), but there’s no coverage for /queue/next. Since this change alters the response contract (nested data.record plus filtered_count, total_count, and schema), please add tests that validate the new shape for both the “record found” and “no record” cases (including filter parameters).