Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(db): deterministic full-scenario seed shared by local dev and dashboard e2e

Abierto
  • ¿Algo no está bien?
#969 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
postgres, typescript
Área
backend, cli, data, database, testing

Línea de trabajo

Start with packages/db/src/seed.ts and apps/dashboard/app/api/test/e2e/clickhouse/route.ts to compare the existing generators, then read packages/db/src/test-env.ts for the loopback safety pattern. Review the Drizzle schema and ClickHouse row types before defining the shared scenario engine. Done means the CLI and e2e use one deterministic generator and an integration test runs the small scenario against test databases.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

@izadoesdev

Problem

Most dashboard pages can't be checked locally without setting data up by hand:

  • bun run db:seed <WEBSITE_ID> [EVENT_COUNT] (packages/db/src/seed.ts) writes only events, outgoing_links, error_spans, and web_vitals_spans. It creates no custom events, revenue, profiles, or uptime history, and no Postgres rows, so goals, funnels, flags, monitors, alarms, and links pages stay empty.
  • Paths are picked at random per event, so any funnel or goal defined on top of the data shows near-zero, meaningless conversion.
  • It never calls faker.seed, so every run produces different data and screenshots can't be compared.
  • Dashboard e2e has a second, separate generator in apps/dashboard/app/api/test/e2e/clickhouse/route.ts, so the two drift independently.
Proposal

One deterministic scenario engine in @databuddy/db, used by both the CLI and e2e:

bun run db:seed --scenario saas --email [email protected] [--size small|large] [--days 90] [--seed 42] [--reset]
  • Ownership: attaches a "Demo" organization and website to an existing local user found by email, so it never bypasses Better Auth. The current db:seed <WEBSITE_ID> [EVENT_COUNT] form keeps working.
  • A coherent story: a fictional SaaS whose sessions follow a journey model (landing → pricing → signup → onboarding → upgrade) with realistic drop-off, so seeded goals and funnels show real conversion. On top of that:
    • matching custom events and revenue for upgrades
    • identified profiles
    • an error spike after a deploy annotation
    • web vitals per page
    • an uptime monitor with history and one incident, plus alarms
    • flags, links, and AI crawler traffic
  • Relative to now: dates are anchored to the current time so default date ranges always show data, and a fixed --seed gives identical output across runs.
  • Safe: refuses to run unless DATABASE_URL and CLICKHOUSE_URL point at a loopback host, like packages/db/src/test-env.ts does.
  • Can't rot silently: inserts are typed against the Drizzle schema and ClickHouse row types, and an integration test runs the small scenario against the test databases in CI.
Delivery plan
  1. Engine plus web analytics: events, custom events, goals, funnels, revenue, profiles, errors, vitals.
  2. Uptime, alarms, status page, links, and flags.
  3. Point the e2e ClickHouse route at the engine and delete its generator.
Questions
  • Is SaaS the right story, or would you rather have e-commerce?
  • Are two sizes (small for UI work, large for query performance) worth it, or is one enough?
  • Should step 3 happen at all, or do you want e2e data kept separate on purpose?

Disclosure: I used Claude Code to compare the seed and e2e generators and to draft this write-up; I verified the file references by hand.

Lenguaje dominante
TypeScript
Estrellas
1.2k
Forks
220
Merge medio
12 h 12 min
PR fusionados (30 d)
295

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databuddy-analytics/Databuddy

Todos los issues de databuddy-analytics/Databuddy

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.