Files
task-stream/libs/api/tracker/application
Josep Piguillem 034704e46f feat: alerts open bugs, and repeats of the same problem go to that bug
Owners and admins turn on a secret URL per project (Settings →
Integrations), POST /api/webhooks/alerts/{project}/{token}, that Sentry,
Uptime Kuma, Prometheus Alertmanager, Grafana or any tool sending JSON
with a title can call. A new problem opens a bug as TaskStream (label
«alerta», chosen type and priority); while that bug is open, the same
fingerprint goes to it (a comment at most every 30 minutes) and
«resolved» is said on it; once it is closed, a new bug names the old
one. Alerts of a project are handled one at a time, so two at once open
one bug, and a bug not yet projected still counts as open. Unknown
project, alerts off or a bad token all answer 403.

TaskStream may now comment as the system actor, like it already opened
tickets for public proposals. Stored in Mongo (alert_integrations,
alert_traces), not in the event store.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 12:36:55 +02:00
..
2026-10-03 13:40:26 +02:00
2026-10-03 13:40:26 +02:00
2026-10-03 13:40:26 +02:00
2026-10-03 13:40:26 +02:00
2026-10-03 13:40:26 +02:00

api-tracker-application

Casos de uso del tracker (CQRS).

  • Import: @task-stream/api/tracker/application
  • Capa: application · Tags: scope:api-tracker, type:application

Contenido

  • Services: ProjectsService, IssuesService, CommentsService, ReleasesService, ChangesService (subscriptions), WorkflowsService (workflow de cada proyecto para presentar tickets, con una caché de 2 s).
  • commands/: un fichero por command y otro por handler; cargan con WriteAccess (rehydrator) y guardan con commitAndWait().
  • queries/: un fichero por query y otro por handler; leen de los puertos Find*Repository y comprueban el acceso (ReadAccess: miembros, o cualquiera si el proyecto es público; viewerId null = anónimo); SearchMyIssuesQuery y GetUpcomingReleasesQuery cruzan todos los proyectos del usuario («Mi trabajo»).
  • event-handlers/: proyecciones (@EventsHandler) hacia el read model (incluida la línea temporal de cada ticket), notificaciones en tiempo real y feed de actividad.
  • sagas/: ProjectDeletionSaga (cascada al borrar un proyecto y sus tickets), ReleaseArchivedSaga (los tickets sin terminar salen de una release archivada) y UserDeactivatedSaga (desasigna los tickets abiertos de un usuario que Pireon desactiva). Las ejecuta el EventsBridge; sus comandos son internos e idempotentes. Tests en sagas.spec.ts.
  • analytics/: estadísticas y burnup calculados con funciones puras sobre la línea temporal (con tests).
  • ports/: lookups de escritura, Find*, UpsertMaterialized*, ReleaseIssuesRepository, ChangeFeed, UserDirectory.
  • TrackerApplicationModule.withInfrastructure(...).

Cómo añadir un caso de uso: Desarrollo.

Comandos

npx nx lint api-tracker-application
npx nx test api-tracker-application    # Jest

Reglas de dependencia entre capas: Arquitectura.