Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

EventStats: compiled queries endpoint for server-side aggregations

Aberta
  • Algo errado?
#116 2 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 2 dias

@tmikula-dev já está trabalhando nisso.

Desde 30/9/2026.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
postgresql, python
Domínio
api, backend, databases

Direção de pesquisa

Comece resolvendo a dependência #115 e revisando o fluxo existente de rotas e handlers do EventStats em event_stats_lambda.py, especialmente ROUTE_HANDLERS, além da PR #113. Confirme com as partes interessadas o conjunto de consultas compatível e os contratos de parâmetros/saída antes de projetar o registro. A conclusão requer testes unitários de routing, registry-lookup e result-shaping, um teste de integração de testcontainer com dados iniciais e uma execução bem-sucedida de ./ci_local.sh.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

enhancement
Feature Description

Extend the EventStats Lambda with a compiled queries endpoint — a curated list of predefined, server-executed queries (e.g. "failed jobs in the last 7 days", "job count aggregated by catalog") that consumers can invoke by name. Rather than pushing aggregation logic into the client or BI tool, the heavy lifting runs inside PostgreSQL and only the final result set is returned over the wire.

Problem / Opportunity

The current POST /stats/{topic_name} endpoint returns raw paginated rows. Consumers (dashboards, reports, downstream tools) re-derive the same aggregations repeatedly on the client side — wasting bandwidth, duplicating logic, and making results inconsistent across consumers. Predefined server-side queries centralise that logic, reduce payload sizes significantly, and allow PostgreSQL query planning to optimise repeated patterns.

Acceptance Criteria
  • A new route (e.g. POST /stats/{topic_name}/query/{query_name}) accepts a query identifier and an optional parameter bag (e.g. time window, tenant filter).
  • A SUPPORTED_QUERIES registry maps each query_name to its SQL template and accepted parameters — unknown names return 400.
  • Queries are executed server-side; only the aggregated result is returned (no raw row streaming).
  • The endpoint is protected by the same JWT auth and per-topic ACL as the rest of EventStats.
  • Unknown or unsupported query_name values produce a clear 400 error, not a 500.
  • Unit tests cover routing, registry lookup, and each query's result shaping.
  • Integration tests validate at least one aggregation query end-to-end against a seeded testcontainer database.
  • All quality gates pass (./ci_local.sh).

Note for implementer: the concrete set of queries and their SQL definitions must be identified and agreed upon as part of this issue's implementation. The examples below are starting points only — validate with stakeholders which aggregations are actually needed before writing SQL.

Proposed Solution

Introduce a CompiledQueryRegistry (or extend ReaderPostgres) that maps query names to parameterised SQL templates (using psycopg2 %s / sql.SQL composition — never string interpolation). Each entry declares its accepted input parameters and output schema.

Example candidate queries to evaluate with stakeholders:

  • failed_jobs_last_7d — count and list of jobs with a failure status in the last N days, grouped by pipeline/tenant.
  • aggregation_by_catalog — job count, success rate, and average elapsed time grouped by catalog/source.
  • run_status_summary — distribution of run statuses (running, completed, failed) over a configurable time window.

Route dispatch follows the existing ROUTE_HANDLERS pattern in event_stats_lambda.py. A new HandlerCompiledQuery (or an extension of HandlerStats) handles validation and delegates to the registry.

Dependencies / Related
  • Builds on the EventStats Lambda introduced in PR #113.
  • Connection pooling (#115) should be resolved first to avoid per-query connection overhead under aggregation load.
Linguagem predominante
Python
Estrelas
4
Forks
0
Merge médio
3d 12h
PRs com merge (30d)
9

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de AbsaOSS/EventGate

Todas as issues de AbsaOSS/EventGate

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.