Shell scripts checked out with CRLF on Windows (core.autocrlf=true) broke
the Docker entrypoint at container start. Force LF for all text files at
the git layer, matching the existing .editorconfig and Prettier settings.
Agreed. ĐANG XÁC MINH is closer to “verifying/confirming” and can imply that the cause is already being checked. In this incident-management context, INVESTIGATING refers to the earlier phase where the team is still looking into the issue, so ĐANG ĐIỀU TRA is more accurate and clearer for Vietnamese users.
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
- Import GetAllSiteData directly from siteDataController instead of the
controller barrel, which re-exports incidentController and creates a
circular import (risk of partially-initialized modules at runtime).
- Pass a stable per-comment deduplication id to subscriberQueue.push so a
retried/double push notifies once; without it the queue falls back to a
Date.now()-suffixed id that never deduplicates.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Manually created/updated incidents never reached the subscriber
notification workflow (#774): only alertingQueue pushed to
subscriberQueue, so dashboard and API incidents stayed silent.
Make AddIncidentComment the single notification choke point: posting a
comment on an INCIDENT-type incident notifies "incidents" subscribers,
regardless of source (alert, dashboard, or API). Remove the two bespoke
pushes in alertingQueue — alert-driven incidents now notify through the
same path via their auto-created comments, instead of twice.
The dedup id is now the comment id (previously the incident id with a
Date.now() suffix, which never deduplicated anything). Alert-created
incident emails now carry the incident state (INVESTIGATING) instead of
the alert status (TRIGGERED) in the subject; body content is unchanged.
Also drop the dead commented-out queueController blocks left from the
old notification system.
Fixes#774
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The field was already stored in the DB, mapped through the controller,
and present on MonitorRecordTyped — but missing from CreateMonitorRequest
and UpdateMonitorRequest, so the API silently dropped it.
- layoutController/site-configurations: use strict boolean check instead of
Boolean() coercion for showInlineEvents so persisted "false" strings don't
flip the toggle
- (kener)/+page.svelte: collapse confusing triple negation !!! to single !
- NotificationsList: add aria-label/title to the icon-only events button
(+ "Open events page" en locale key)
- move NotificationEvent into shared $lib/types/notifications so client code
no longer imports from the server dashboardController; controller re-exports
it for backwards compatibility
- [page_path] and monitor pages: pass hideNotificationsPopover={showInlineEvents}
to ThemePlus so inline and popover event surfaces stay mutually exclusive
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
GET / was throwing KnexTimeoutError ("Timeout acquiring a connection")
in production. Root cause was the connection pool, not the database:
the single process (SvelteKit + cron scheduler + BullMQ workers) shared
one pool capped at 10, while one GET / fans out ~6 queries. A couple of
concurrent page loads, or a per-minute monitor burst overlapping a load,
exceeded 10 and queued acquires blew past the 15s timeout. Postgres
itself had 97 free slots the whole time and no leak.
Split into two pools so background work can't starve page loads:
- web pool (DATABASE_POOL_MAX, default 10) serves HTTP requests
- worker pool (DATABASE_WORKER_POOL_MAX, default 5) serves background jobs
Routing is by execution context via AsyncLocalStorage: q.createWorker
(the single chokepoint all workers/schedulers flow through) runs each
processor inside a worker-pool context, and BaseRepository.knex resolves
the pool from that context, defaulting to the web pool. This keeps shared
controllers correct whether they run in a request or a job. SQLite has no
real pool and reuses a single connection, so the split is a no-op there.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Florian Kostenzer
github-actions[bot]
Raj Nandan Sharma
Logesh K
lokiee0
alberta
Phi ND
Phi Nguyen
TTurletti
phatlet
Jorge Hermes
Crazy Computer
Kanishk Sachdev