[Feat]: Query history: filter by outcome and time range

Closed
  • Is something wrong?
#859 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@Detoy is already working on this.

Since Oct 9, 2026.

  • #931 by @qwist1233-cpu — closed without merging
  • #943 by @Detoy — merged

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
78/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
react, typescript
Domain
frontend

Research direction

Start with src/components/layout/sidebar/QueryHistorySection.tsx and src/types/queryHistory.ts to understand the existing search and the status and executedAt fields. Add a pure filtering helper under src/utils/ and unit-test it; check src/i18n/locales/ for the required UI strings. Done means outcome and time filters combine with text search, the counter appears when any filter is active, and the PR notes whether filters reset or persist.

Written by the indexing model from the issue text.

Description

feature request good first issue
🚀 Feature Proposal

Add two filters to the Query History panel, next to the existing search box:

  • Outcome: Any / Succeeded / Failed
  • Time range: All time / Last hour / Today / Last 7 days / Last 30 days
Motivation

A long history is hard to use with text search alone. "Show me only the queries that failed today" is a very common need when debugging.

Where to start
  • Frontend only: entries already carry status and executedAt (src/types/queryHistory.ts).
  • src/components/layout/sidebar/QueryHistorySection.tsx: add two compact selects and extend the filteredEntries memo.
  • Put the filtering logic in a pure helper under src/utils/ so it can be unit-tested.
Acceptance criteria
  • Outcome and time filters combine with the text search.
  • The existing "filtered / total" counter shows whenever any filter is active.
  • Decide whether filters reset per session or are remembered, and note it in the PR.
  • Unit tests for the filter helper.
Contributor notes
  • Follow the repo rules in .rules/ (TypeScript, React, design tokens, accessibility, testing).
  • Any new UI string needs a key in every locale under src/i18n/locales/.
  • Run pnpm lint, pnpm typecheck and pnpm test before opening the PR.
  • Questions? Ask here or on Discord.
Dominant language
TypeScript
Stars
5.1k
Forks
335
Avg merge
1d 7h
Merged PRs (30d)
255

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TabularisDB/tabularis

All issues in TabularisDB/tabularis

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.