* feat(stack): per-stack activity timeline with actor attribution
Adds an Activity tab to the Stack Anatomy panel showing a timestamped
event log for each stack: deploys, restarts, starts, stops, and image
updates, attributed to the user who triggered them or 'system' for
automated actions.
Backend:
- Extends notification_history with actor_username column (idempotent
migration) and a partial composite index on (node_id, stack_name,
timestamp DESC) for efficient per-stack lookups.
- NotificationService.dispatchAlert() accepts an optional actor that
is written to the new column.
- Success-side dispatchAlert calls added after deploy, bulkContainerOp
(start/stop/restart), and update handlers in routes/stacks.ts so
user-initiated operations are recorded, not just failures.
- New GET /api/stacks/:stackName/activity?limit&before endpoint with
stack:read permission gate and cursor-based pagination.
Frontend:
- StackAnatomyPanel grows an Anatomy / Activity tab pair using the
existing Tabs primitive.
- StackActivityTimeline fetches the initial 50 events, paginates on
demand, and prepends live events arriving over the existing WS
notifications stream without duplicates.
- NotificationPanel bell dropdown suppresses user-initiated success
events (start/stop/restart/deploy/update triggered by a real user),
keeping the tray focused on alerts and system events.
* docs(stack): add stack activity timeline feature page and internal arch docs
* fix(test): add actor_username to notification-routing history assertions
dispatchAlert now passes actor_username to addNotificationHistory after
the activity timeline PR added the column. Update the two exact-match
assertions that were failing because the expected object shape was missing
this field.
* feat(sidebar): bulk stack operations (select, start/stop/restart/update)
- Add ⊞ bulk mode toggle in SidebarActions (cyan active state, tooltip "Bulk
mode (B)"); keyboard shortcut B toggles, Esc exits, Ctrl+A selects all
visible (chip-filtered) stacks
- Reserved checkbox column in StackRow becomes visible and interactive in bulk
mode; clicking a row in bulk mode toggles selection instead of opening the
stack; kebab and context-menu still work in either mode
- SidebarBulkBar appears below filter chips when >=1 stack selected: shows
count, Start / Stop / Restart / Update actions; Update is disabled with a
Skipper TierBadge for Community licenses
- useBulkStackActions hook fans out operations via Promise.allSettled and
surfaces an aggregate toast ("3 of 4 restarted; 1 failed: plex")
- Bulk update enforced Skipper-gated frontend-side (isPaid check in hook) and
sends x-bulk-mode header for backend defense-in-depth
- Extract isInputFocused / isPaletteOpen to lib/keyboard-guards.ts; both
useStackKeyboardShortcuts and the new bulk keyboard effect now share the
same guards instead of duplicating the logic
- chipFilteredFiles captured via useRef in bulk keyboard effect so the listener
is not torn down and re-added on every status-poll cycle
* fix(sidebar): separate TooltipProviders for bulk and scan icon buttons
Wrapping both icon buttons in a single TooltipProvider made them
render as one flex child, collapsing the gap-2 between them.
Splitting into two independent TooltipProviders restores the 8px
gap and right padding of the scan button.
* feat(sidebar): §14 sidebar orchestration (filter chips, pinned rail, trailing column)
- Add All / Up / Down / Updates filter chips with live counts; active chip
filters the list; chip-filtered files computed in EditorLayout with useMemo
- Surface the PINNED group with a 3px cyan left rail and glow via the
sidebarPinnedGroupRail token; reuses the brand token already on the active row
- Compact brand row from three stacked elements to a single 44px horizontal bar
- Restructure StackRow trailing column as fixed slots: label dots (max 3 + +N
overflow), update-dot | git-pending icon (priority order), kebab; add reserved
invisible checkbox slot for PR2 bulk mode
- Export statusText / statusColor from StackRow and reuse them in StackList
remote-results section to remove the duplicate inline logic
- Lift filterChip state and chip-filtered files to EditorLayout; remove
filterChip from StackListProps to eliminate the dual-path redundancy
- Remove unused labels param from buildGroups and the void labels workaround
- Wrap filteredFiles in useMemo so filterCounts memo is not defeated on every
render
* fix(sidebar): move statusText and statusColor to stack-status-utils
react-refresh/only-export-components requires component files to export
only components. Move the two utility functions and StackRowStatus type
to a dedicated stack-status-utils.ts so StackRow.tsx is a pure component
module. Update StackList.tsx and EditorLayout.tsx to import from the new
source directly.
* feat(settings): dress the page to match the audit (cyan rail, italic serif, two-column rows)
Brings the full-page Settings route into the Sencho voice. The page now
opens with a full-width PageMasthead (cyan rail, mono crumb, italic
serif title, contextual stat strip) above a sidebar and main-content
panel, each as a rounded-xl card inset on the dark background.
Sidebar drops the duplicate "Settings" header and the candy tier badges.
Group headers carry mono labels with visible/total counts; gated rows
get a neutral uppercase lock chip and dim. Active rows keep the cyan
2px rail.
Five new primitives (SettingsSection, SettingsField, SettingsCallout,
SettingsActions / SettingsPrimaryButton, TierLockChip) replace the
stacked label-input-help shadcn defaults and the per-section ad-hoc
chrome. AccountSection, AppearanceSection, LicenseSection, SystemSection,
NotificationsSection, DeveloperSection, AppStoreSection, AboutSection,
and SupportSection are migrated to the new layout. The list-driven
sections (Webhooks, Routing, Users, Labels, Security, CloudBackup,
ApiTokens, Registries, NodeManager, SSO) keep their list cards but get
the new chrome and primary CTAs.
Each section can publish contextual stats to the masthead via a small
context channel: 2FA state on Account, plan/trial/renews on License,
edited count on System, channel counts on Notifications, etc.
* refactor(settings): drop react-router-dom and align with DESIGN.md
The Settings page was the only surface using react-router-dom for sub-section
navigation. Every other primary view (Home, Fleet, Resources, App Store,
Schedules, etc.) drives view switching through a single activeView useState in
EditorLayout. This change removes the dependency end-to-end:
- App.tsx drops BrowserRouter
- EditorLayout adds 'settings' to the activeView union; SettingsPage renders
inside the same flex-1 overflow-y-auto p-6 wrapper as siblings
- UserProfileDropdown receives an onOpenSettings callback instead of
useNavigate. SettingsPage owns currentSection via props lifted to
EditorLayout, so cross-component navigation (openLabelManager,
onManageNodes, ConfigurationStatus rows) can route to a sub-section
- SettingsSidebar items become buttons (no more NavLink); SectionGate's
redirect-on-invisible falls back through SettingsPage's safeSection memo
- e2e/nodes.spec.ts updates the Nodes selector from link to button role
- react-router-dom removed from package.json + package-lock.json
The visual treatment is brought into alignment with frontend/DESIGN.md,
which was rewritten this week to be the normative extract of the audit:
- PageMasthead: title text-3xl → text-[22px] Section rung italic; kicker
11px → 10px Label rung; stat label tracking 0.22em → 0.18em; stat value
font-medium for mono Stat-rung family discipline
- SettingsField helper: mono → sans Body rung 14/22; success tone now uses
--success green (was incorrectly mapped to brand cyan)
- SettingsCallout: title tracking 0.18em; subtitle Body rung 14px; success
tone now genuinely uses --success green; new brand tone for promotional
callouts (Trial CTA, Admiral upgrade) that should read cyan
- SettingsActions: SettingsPrimaryButton renders mono uppercase tracked,
size sm by default. DESIGN §9.10 requires "small mono uppercase, cyan-
filled" for every Settings primary CTA
- TierLockChip: 9px → 10px Label rung floor
- SettingsSidebar: group header tracking 0.18em; ⌘K kbd 9px → 10px;
aside gains text-card-foreground transition-colors per §10 canonical
card class
- SettingsPage main panel: text-card-foreground transition-colors added;
uses h-full overflow-auto p-6 to mirror FleetView's wrapper rhythm
- Field rows, section headers, action rows now consume var(--density-*)
tokens with literal fallbacks so Settings respects the comfortable/
compact toggle
* fix(e2e): update mfa openAccountSettings to match settings redesign
Settings now opens to the Account section by default when accessed from
the profile dropdown, and the Account section no longer renders an h2
heading element. Update the openAccountSettings helper to open the
correct section and assert on the Password h3 heading that SettingsSection
renders instead.
* test(e2e): fix MFA enrolment assertion after settings redesign
The 2FA enrolment badge was replaced with a kicker/field pattern.
Assert on the 'enrolled' text that the new design renders instead of
the removed Enabled badge.
* test(e2e): fix low-backup-codes warning assertions after settings redesign
Update two assertions in the 'low backup codes warning' test that
referenced UI text removed in the settings redesign:
- '1 backup code remaining' -> '1 remaining' (SettingsField body text)
- 'Regenerate now' button -> callout subtitle text, which uniquely
identifies the zero-codes error card without hitting strict-mode
from two identically-labelled Regenerate buttons on the page
* test(e2e): navigate to root before re-opening settings for mock refresh
The settings redesign uses a nested full-page route. Navigating to the
same URL a second time does not remount the component, so AccountSection
retains cached MFA state and the 0-codes branch never fetches. A
page.goto('/') ensures full unmount before the second openAccountSettings
call, so the refreshed mock is actually hit.
* test(e2e): scroll zero-codes callout into view before asserting visibility
The callout sits below the Disable 2FA section in the MFA settings page
and is scrolled out of the clipped content area on initial render.
scrollIntoViewIfNeeded() brings it into the visible viewport before the
toBeVisible assertion.
* test(e2e): scroll Radix ScrollArea viewport for zero-codes callout assertion
The settings page wraps content in a Radix ScrollArea whose Root has
overflow:hidden, so the browser's native scrollIntoView cannot scroll
the inner viewport. Wait for the callout to attach (confirms mock data
loaded), then programmatically set scrollTop on the Radix viewport
element before asserting visibility.
* test(e2e): use toBeAttached for zero-codes callout to avoid Radix clip issue
The callout renders below the Disable 2FA section, outside the visible
clip area of the Radix ScrollArea Root (overflow:hidden) on a standard
viewport. Playwright's visibility check uses the clip intersection, so
toBeVisible() fails even after programmatic scroll. toBeAttached()
confirms the component rendered the warning card for backupCodesRemaining:0
without depending on the element's scroll position.
* refactor(settings): replace modal with nested full-page route
Settings sections are now URL-addressable at /settings/:sectionId, rendered
nested inside EditorLayout alongside the stack sidebar. Browser back/forward
navigates between sections. Deep links (e.g. /settings/cloud-backup) load
the section directly on hard reload.
- Add react-router-dom v7; BrowserRouter wraps the full app tree
- New SettingsPage (scroll memory, Cmd+K palette), SettingsSidebar (NavLink
active styling, back-arrow), SectionGate (visibility + tier lock card)
- Rename SectionId 'appstore' to 'app-store' so slug === SectionId
- Decouple SystemSection, DeveloperSection, AppStoreSection from modal-
passed props; each fetches its own data on mount
- Replace onLabelsChanged prop chain with SENCHO_LABELS_CHANGED window event
- Drop onOpenSettings prop from UserProfileDropdown, HomeDashboard,
ConfigurationStatus; each calls useNavigate directly
- Delete SettingsModal.tsx
* fix(settings): validate sectionId against registry before property write
Prevents prototype pollution (CodeQL js/remote-property-injection #243).
URL param sectionId is checked against SETTINGS_ITEMS before being used
as a property key on scrollPositionsRef.
* fix(settings): eliminate remote property injection via Map and registry-sourced key
Two-part fix for CodeQL js/remote-property-injection:
1. currentSection is now derived from SETTINGS_ITEMS.find().id (trusted
registry data) instead of the raw sectionId URL param. The tainted
string never flows into any property access.
2. scrollPositionsRef uses Map<SectionId, number> with .get()/.set()
instead of a plain object. Map operations do not write to the prototype
chain, removing the prototype pollution vector entirely.
* test(e2e): align settings selectors with full-page route
The settings refactor (4475afd) replaced the modal with a nested route.
The new sidebar renders sub-sections as NavLinks (role link, not button)
and adds a "Filter settings" button that collides with the loose
/settings/i regex used in mfa and nodes specs.
- Use exact 'Settings' match for the profile-dropdown menu row
- Switch the Nodes sub-section selector from button to link role
README: rewrite to lead with differentiation rather than a flat
feature list. Add "Why Sencho?" section covering the four key
competitive advantages (Pilot Agent NAT traversal, auto-heal
self-healing, atomic deployments, automation-first model). Expand
feature coverage from 8 bullets to six grouped domains reflecting
the full 38-feature surface. Add architecture note, docker run
one-liner, tier comparison table (Community/Skipper/Admiral), and
docs link section. Drop stale CI badge; add Docker Pulls badge.
CONTRIBUTING: add project layout reference, tier-gate usage guide,
TypeScript strictness reminder, and pointer to CLAUDE.md for full
coding standards.
SECURITY: update supported versions table from stale "0.2.x+" to
current "latest release" policy with a note on self-hosted update
cadence.
EditorLayout owned the stack-image-update state plus a 5-minute
polling interval as part of a 30-line useEffect that already
juggled six other concerns (selected file, active view, stacks
refresh, auto-update settings, git-source pending, …). The image-
update slice has clean boundaries: it depends on activeNode.id,
mutates one state object, and is otherwise unrelated to the rest
of the effect.
Move it into a dedicated hook at frontend/src/hooks/useImageUpdates.ts.
The hook owns the stackUpdates state, runs an initial fetch on
activeNode.id change, schedules the 5-minute poll, and exposes a
refresh() callback for the four manual-trigger sites
(deploy success, image-update action, manual registry-refresh
poll). The hook destructure aliases refresh to fetchImageUpdates so
existing call sites in EditorLayout don't need to be renamed.
This is the first slice of audit finding 1.6 (EditorLayout 3129-line
refactor); the next slice is useFleetNotifications.
DockerController.pruneManagedOnly removed managed volumes,
networks, and images one at a time inside a serial for-await loop.
Each remove call hits the Docker daemon over the Unix socket with a
synchronous-from-the-caller's-perspective HTTP round-trip, so a
prune over N items took the sum of N round-trips. The daemon
handles concurrent removes fine for these resource types.
Wrap each loop in Promise.all so wall time tracks the slowest
single remove rather than the sum. The existing per-item try/catch
keeps the partial-failure semantics: a single resource that fails
to delete logs and continues; the rest still get removed.
JavaScript single-threading makes the shared reclaimedBytes
counter safe under the parallel awaits.
Each test file's setupTestDb() previously re-ran the full
DatabaseService init path: initSchema (~30 CREATE TABLE IF NOT
EXISTS), 14 idempotent migrate*() methods, a bcrypt hash, and the
admin / settings seed inserts. With 82 files this was a meaningful
slice of the per-fork cold-start cost.
Move the build into a vitest globalSetup that runs once before any
worker boots. The baseline DB lands at a fixed temp path; each
worker's setupTestDb copies it into the per-file data dir, opens the
copy via DatabaseService.getInstance() (re-running the same
idempotent init as a no-op pass), then UPDATEs the seeded local
node's compose_dir to match the per-file COMPOSE_DIR (the baseline
recorded /app/compose because COMPOSE_DIR was unset when the seed
fired in initSchema; without realigning, file-routes tests 400 on
path traversal).
TEST_JWT_SECRET moves from a per-file randomBytes assignment to a
fixed constant in a new testConstants module so the value the
baseline seeds matches the value test files import for direct token
signing. setupTestDb re-exports it for back-compat with the existing
import sites.
A baseline-less measurement on the same machine flakes 30 of 82
files at the no-cap baseline; with this baseline copy, the same
tree drops to 0-3 failures (the residual environmental Windows
flakes) and ~47-52 s wall time.
Vitest's fork pool default scales with availableParallelism, which
on machines with many cores spawns dozens of fresh workers. Each
worker dynamic-imports the full Express stack (TypeScript transform
+ DB constructor + every migration) and saturates CPU on cold start.
Most of the previous suite wall time was spent waiting on this
contention rather than running tests.
Cap concurrency at 4 workers via the new top-level maxWorkers /
minWorkers options (Vitest 4 unified the previous
poolOptions.forks.maxForks under maxWorkers across pool types).
Local backend wall time drops from ~93 s to ~32-60 s on typical
runs. The pre-existing pre-cap fork-contention flakes (rate
limiting, metrics-routes, fleet integration) clear consistently
on the warm path; the remaining variance is environmental
(background processes, antivirus on Windows) and is what it was
before this change minus the contention floor.
testTimeout (30 s) and hookTimeout (45 s) stay generous so the
stress path in database-metrics and the HTTP integration suites
still cover their cold-start envelope on slow runners.
backend/tsconfig.json had no incremental setting, so every tsc run
re-checked the full project from cold. The two frontend tsconfigs
already declared a tsBuildInfoFile path under node_modules/.tmp/ but
without incremental: true the file was never written, and the path
itself sits inside node_modules where npm ci wipes it on every fresh
install — neither of which actually persists incremental state.
Add incremental: true to all three configs and drop the broken
tsBuildInfoFile overrides. TypeScript's default places the buildinfo
next to the tsconfig (e.g. backend/tsconfig.tsbuildinfo); the root
.gitignore already covers *.tsbuildinfo so nothing leaks into git.
Local cold-vs-warm tsc --noEmit on the backend dropped from ~3.0s
to ~1.4s — ~2x speedup on the warm path. CI builds are still cold
because runners do not cache the buildinfo between jobs; that is a
separate workflow change.
* perf(frontend): parallelize auth bootstrap fetches
AuthContext.checkAuth previously chained three sequential fetches:
/api/auth/status, then /api/auth/check, then /api/permissions/me.
The status check has to come first because its response decides
whether to early-return on the setup or mfa-pending path. The next
two are independent for an authenticated session and were costing
an extra round-trip on every cold load.
Run /api/auth/check and /api/permissions/me in parallel via
Promise.all. The permissions request is wasted on the rare
not-authenticated path (cookie expired or logged out) but that
trade-off is worth saving the round-trip on the common success
path. The .catch(() => null) on the permissions fetch and the
inner try/catch around .json() preserve the original fault
tolerance: a network failure or malformed body falls back to no
permissions data, with the global role still authoritative.
* fix(frontend): commit auth state without waiting on /permissions/me
The previous Promise.all awaited both fetches before calling
setAppStatus('authenticated'), so a slow /api/permissions/me would
delay the dashboard commit relative to the old serial code. The E2E
deploy-feedback tests at e2e/deploy-log-panel.spec.ts:168 and :236
race the dashboard render after page.reload() and were timing out
waiting for GET /api/stacks/<name> because the click target was not
yet wired when the slower permissions response held up state.
Keep both requests in parallel on the wire, but await only the auth
check before committing state. The permissions promise resolves in
the background and updates state via void permsPromise.then() so the
non-critical request never gates the bootstrap.
xterm-the-terminal-emulator and its three addons (fit, search,
serialize) used to be imported at module scope by Terminal.tsx,
BashExecModal.tsx, and HostConsole.tsx along with xterm's CSS.
Even though only Terminal.tsx is rendered eagerly inside the editor
layout, the static imports forced the ~660 KB xterm chunk plus the
xterm.css bytes into every cold app start regardless of whether a
user ever opened a terminal.
Move the bootstrap into a new frontend/src/lib/xtermLoader.ts
module. loadXtermModules() Promise.alls the four addon imports plus
the CSS, caches the result on a shared promise, and returns the
constructors. On rejection the cache is cleared so the next mount
can retry instead of rethrowing the same failed promise.
Three consumers (Terminal, BashExecModal, HostConsole) swap their
value imports for type-only InstanceType aliases from the loader,
then call loadXtermModules() inside their existing useEffect. A
mounted/cancelled flag in each effect closure prevents
initialisation if the component unmounts during the load.
The vite.config.ts manualChunks group from #823 already groups all
@xterm/* packages into the xterm chunk, so it now loads on demand
instead of being bundled into the entry chunk.
Monaco-editor and @monaco-editor/react were imported eagerly from
main.tsx so that the locally-bundled Monaco was registered with
@monaco-editor/react (CSP blocks the default CDN load). This pulled
the ~3 MB monaco chunk into every cold app start regardless of
whether a user ever opened the editor.
Move the Monaco setup into a new frontend/src/lib/monacoLoader.tsx
module that exports React.lazy-wrapped Editor and DiffEditor
components. The lazy factory awaits a one-shot setupMonaco() that
dynamic-imports monaco-editor, @monaco-editor/react, and the editor
worker, then calls loader.config({ monaco }) and sets
window.MonacoEnvironment before resolving the underlying component.
Concurrent first mounts share a single setup promise so the work
runs at most once per process. The three consumers (EditorLayout,
FileViewer, GitSourceDiffDialog) wrap their editor in <Suspense>
with a transparent fallback that preserves layout while the chunk
loads.
main.tsx loses three eager imports plus the MonacoEnvironment +
loader.config bootstrap. The vite.config.ts manualChunks group from
PR #823 was already prepared for this; the monaco chunk now loads
on demand instead of being bundled into the entry chunk.
* perf(frontend): split heavyweight vendors into manual chunks
Vite's default chunking grouped monaco-editor, the xterm addons,
recharts, @xyflow/react + @dagrejs/dagre, and motion into shared
chunks with the Sencho app code. Any small change in the app would
bust the cache for the heavyweight vendor code, costing repeat
visitors a fresh download.
Add explicit manualChunks for monaco, xterm, charts, flow, and
motion. Each vendor is large enough to justify its own HTTP/2
stream, and grouping them by library keeps their cache key stable
across feature releases.
Also wire rollup-plugin-visualizer behind ANALYZE=true so
`ANALYZE=true npm run build` emits dist/stats.html for ad-hoc
bundle inspection without affecting CI or production builds.
Bump build.chunkSizeWarningLimit from the default 500 KB to 1500 KB
since the monaco chunk is intentionally large; this preserves the
warning's signal value for genuine future regressions.
* fix(frontend): use manualChunks function form for vite 8 typing
Vite 8's OutputOptions overload narrows manualChunks to the
ManualChunksFunction shape, so the object form rejected the chunk
keys with TS2769. Convert to the equivalent function form using
node_modules path matching; same chunk groupings as before.
Also pin rollup-plugin-visualizer to ^6.0.0; 7.x raised the engine
floor to Node 22 and CI runs Node 20, so npm emitted EBADENGINE
warnings. Version 6 supports Node 18+ and exposes the same
visualizer({ filename, gzipSize, brotliSize }) API.
Both frontend-builder and backend-builder ran `npm install` even
though `prod-deps` already used `npm ci`. `npm install` walks the
dep graph and silently rewrites the lockfile when there is drift,
which costs build time and lets a stale lockfile slip into a release
image. `npm ci` enforces the lockfile, fails fast on drift, and skips
the resolution work since the dep tree is fully described by the
lockfile.
Both lockfiles are in sync (verified with `npm install
--package-lock-only` reporting "up to date"), so the change is a
pure tightening with no behavior delta in the happy path.
@aws-sdk/client-ecr and @aws-sdk/client-s3 each pull in dozens of
@smithy/* and middleware-* transitive packages but only fire when an
operator configures an ECR registry or cloud backup respectively. Move
both to optionalDependencies so the package classification matches
their runtime role and operators who never use either feature can run
`npm ci --omit=optional` for a ~150 MB-slimmer image.
The default Dockerfile install (`npm ci --omit=dev`) keeps shipping
the SDKs, so default installs are unchanged. The dynamic imports in
CloudBackupService.loadS3Sdk and RegistryService.fetchEcrToken now
catch a missing-module failure and throw a wrapped Error whose
message names the recovery path (`reinstall without --omit=optional`)
and whose cause propagates the original module-not-found error for
debugging.
Bumps tsconfig.json's target and lib to ES2022 so `new Error(msg,
{ cause })` is typed; Node 25 already supports this at runtime.
@aws-sdk/client-s3 pulls in dozens of @smithy/* and middleware-*
transitive packages. Cloud backup is a Skipper+ opt-in feature and
the bulk of installs never configure it, but the eager top-level
import meant every cold start parsed the whole SDK regardless.
Wrap the import in a load-and-cache helper, make buildS3Client
async, and have it return both the S3Client and the SDK namespace
so each caller constructs commands from the same lazily-loaded
module. The pattern matches the existing dynamic import of
@aws-sdk/client-ecr in RegistryService and the lazy-loaded
composerize and isomorphic-git in PR #819.
Tests use vi.mock('@aws-sdk/client-s3', ...) returning named
exports, which works the same way for dynamic imports as it did
for the static ones.
Both modules are opt-in:
- composerize (~2 MB) is only used by /api/convert when a user pastes a
docker run command into the converter UI.
- isomorphic-git plus isomorphic-git/http/node (~5 MB combined) only fire
when a stack is created from a Git source.
Previously each was imported at module scope, parsing the whole package on
every cold start regardless of whether the feature was used. Wrap them in
small load-and-cache helpers so the first call resolves the module via
Node's loader and every subsequent call returns the cached reference.
The pattern matches the existing dynamic import of @aws-sdk/client-ecr in
RegistryService. Existing tests using vi.mock('isomorphic-git', ...) and
vi.mock('isomorphic-git/http/node', ...) keep working without changes
because dynamic and static imports share the same module registry.
MonitorService.evaluate() forked the docker CLI every 30s and
walked the human-readable Reclaimable strings ("1.196GB", etc.)
with a regex to compute the janitor threshold check. The Docker
Engine API returns raw byte counts, and the existing
DockerController.getDiskUsage() already wraps it for images,
containers, and volumes. Extend that helper with reclaimable
build-cache bytes so MonitorService can sum the four categories
in one call.
Drops the child_process / promisify imports from MonitorService and
removes about 30 lines of stdout parsing. Also widens the explicit
return type of getDiskUsageClassified so the new fields aren't
silent runtime additions.
Every mutating /api/* request runs an individual INSERT into audit_log
which serializes against other writers under burst load (SQLite's
single-writer model). Buffer the writes in DatabaseService and flush
them in a single transaction either every second or once the buffer
reaches 100 entries, whichever comes first.
Read paths (getAuditLogs, getAuditLogsInRange, cleanupOldAuditLogs)
drain the buffer first so callers always see a consistent view, which
keeps the existing test pattern of insert-then-read working.
Graceful shutdown flushes before db.close() so no entries are lost on
clean exit. The 1s flush timer is unref'd so the buffer cannot keep
the process alive on its own. The CLI resetMfa script flushes
explicitly before returning since it exits before the timer fires.
The boot path awaited SelfUpdateService.initialize, DockerEventManager.start,
and TrivyService.initialize one at a time even though none of them depend on
each other. Group them into a single Promise.all so total cold-start time is
the slowest one rather than the sum.
Also convert the inner `docker compose version` probe in
SelfUpdateService.initialize from execFileSync to execFileAsync. Without that,
the synchronous spawn would block the event loop for up to 5 seconds and
silently serialize the other two members of the parallel block, defeating
the parallelization win for in-container deployments.
The synchronous service starts (Monitor, AutoHeal, ImageUpdate, Scheduler,
Mfa) are grouped together up front. They schedule timers whose first ticks
fire 5+ seconds out, so they safely run alongside the awaited block.
The remote-node HTTP proxy and WebSocket forwarder read getTier() +
getVariant() on every forwarded request to set the Distributed License
Enforcement headers. Each call hits system_state 5+ times. Add a
30-second cached snapshot inside LicenseService and route every
license_status write through a new private setLicenseStatus() helper
so activate, deactivate, validate, and the auto-demote paths inside
getTier() all invalidate the cache.
Routing all license_status writes through one chokepoint also closes
a latent drift window: the self-heal paths in getTier() (trial
expired, offline grace exceeded, subscription expired) used to mutate
state silently and now invalidate the cache the same way explicit
license events do.
The TTL becomes a safety net against any future write that bypasses
the helper, not a load-bearing freshness bound. Existing 44 license
and distributed-license tests pass unchanged.
getGlobalSettings() runs a SELECT * on every call and is hit from 22
files, including the auth middleware (every authenticated request),
the WebSocket upgrade handler (every connection), and the debug-mode
gate (every diagnostic log line). Cache the result inside the service
on first read and invalidate on updateGlobalSetting().
The cached snapshot is Object.freeze'd and the public return type is
now Readonly<Record<string, string>> so accidental mutations are
caught at compile time. The settings GET handler that delete'd private
keys now takes a defensive shallow copy first.
The 5-second TTL cache in utils/debug.ts is now redundant and removed;
the service-level cache is strictly fresher (invalidates on write
rather than going stale for up to 5s).
The seven @types/* packages contain only TypeScript declaration files,
which are erased at compile time and have no runtime use. Listing them
under dependencies kept them installed in the production image for no
benefit; they belong under devDependencies so `npm ci --omit=dev`
prunes them from the runtime install.
Packages moved: @types/compression, @types/cors, @types/dockerode,
@types/express, @types/http-proxy, @types/semver, @types/ws.
Anso