fix(helpers): add TTL cache to dir_size_gb to prevent blocking rglob walks#19
Open
boffin-dmytro wants to merge 91 commits intomainfrom
Open
fix(helpers): add TTL cache to dir_size_gb to prevent blocking rglob walks#19boffin-dmytro wants to merge 91 commits intomainfrom
boffin-dmytro wants to merge 91 commits intomainfrom
Conversation
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4.3.0 to 8.0.1. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](actions/download-artifact@d3f86a1...3e5f45b) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-version: 8.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
5 services had optional env_vars without default values in their manifest.yaml files. This makes the CLI and dashboard unable to determine sensible defaults for these settings. Changes: - ollama: OLLAMA_MODEL defaults to 'llama3' - piper-audio: PIPER_VOICE defaults to 'en_US-lessac-medium' - dify: 4 env vars now have explicit defaults - librechat: CREDS_KEY/CREDS_IV default to empty (setup.sh generates) - aider: API keys default to empty (use local LLM) Note: This complements PR Light-Heart-Labs#716 which adds defaults to compose.yaml files for Docker validation. This PR adds defaults to manifest.yaml for CLI/dashboard discovery.
Per review feedback from @Lightheartdevs: - sk-dreamserver prefix mimics real OpenAI keys - Could trigger secret scanners (gitleaks) - Changed to dummy-key (matches previous implied default)
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 6. - [Release notes](https://github.com/actions/checkout/releases) - [Commits](actions/checkout@v4...v6) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
The file contains two U+F07C private-use-area characters in its name and a 20-byte JSON fragment as its contents. It was accidentally committed alongside an unrelated Windows CUDA fix (editor paste accident). Removing it prevents breakage on Windows tooling — git clones, archive tools, and MSI packaging — that rejects filenames containing private-use-area Unicode codepoints.
The macOS installer writes .compose-flags using installers/macos/docker-compose.macos.yml — this overlay sets llama-server replicas=0 (it runs natively via Metal), adds the llama-server-ready sidecar, and routes dashboard-api OLLAMA_URL to host.docker.internal. Cache regeneration through resolve-compose-stack.sh previously selected docker-compose.apple.yml instead, which tries to run llama-server in Docker (no linux/arm64 image), drops the env overrides, and breaks startup ordering. Any cache miss on macOS (dream enable/disable, template apply, manual flag delete) reproduced the broken stack. Detect Darwin via platform.system() inside the Python heredoc and substitute the overlay path in both branches that previously hardcoded docker-compose.apple.yml (the AP_* tier branch and the gpu_backend == "apple" branch). Linux and Windows callers — including Linux CI with --gpu-backend apple — keep selecting docker-compose.apple.yml because platform.system() != "Darwin" there.
…ry source path - Compute launchd PATH at install time via command -v docker and brew --prefix for both the dream host-agent and OpenCode plists, fixing host-agent startup on non-default Homebrew/Docker prefixes. - Surface launchctl bootstrap errors instead of silencing them, and emit a recovery hint when 'Input/output error' (throttle state) is detected. - Fix extensions-library copy source to climb from dream-server/ to repo root via an added '..' segment, and warn (instead of silently skipping) when the source directory is not found.
Baserow embeds Caddy which routes based on Host header matching
BASEROW_PUBLIC_URL (default http://localhost:3007). The previous
healthcheck sent Host=127.0.0.1, which failed the named-matcher and
returned 404 "Site not found", marking the container unhealthy even
though the service was working. Adding -H "Host: localhost:3007"
matches the default BASEROW_PUBLIC_URL host so the healthcheck
returns 200. Caddy's {http.request.host} placeholder strips the port
before the matcher runs, so the tightened header is also forward-
defensive if the Caddyfile ever switches to {http.request.hostport}.
The paulgauthier/aider image declares ENTRYPOINT ["/venv/bin/aider"], so the compose `command:` tokens were appended as argv to aider. Aider interpreted "sh", "-c", "echo ..." as config-file paths and crashed with "Unable to open config file: sh" (exit 2). Override `entrypoint: ["echo"]` so the container becomes a one-shot helper-message printer: it echoes the usage hint and exits 0. Combined with the existing `restart: "no"`, the container no longer crash-loops and new operators get a clear message telling them how to actually use aider (`docker compose run --rm aider <files>`).
…yout Library extensions are copied to data/user-extensions/<id>/ at install time, so bind-mount host paths in compose.yaml must be relative to that install directory, not the repo's extensions/services/<id>/ layout. The nginx.conf and entrypoint.sh mounts pointed at ./extensions/services/continue/config/continue/..., which does not exist under data/user-extensions/continue/. Correct them to ./config/continue/... which resolves to data/user-extensions/continue/config/continue/<file> after install. The ./data/continue volume is unchanged — it was already correct. Mount targets inside the container are also unchanged.
…/Logs to avoid xpcproxy sandbox denial
The generated com.dreamserver.opencode-web and com.dreamserver.host-agent
plists wrote StandardOutPath/StandardErrorPath under ${INSTALL_DIR}/data/,
which xpcproxy's sandbox denies file-write-create on any volume outside
$HOME. The launchd spawn aborts with EX_CONFIG (78) before the target
process ever runs, leaving `launchctl list` showing the service forever
stuck at exit 78 and no log file produced.
Point both plist blocks at $HOME/Library/Logs/DreamServer instead, which
is always inside xpcproxy's sandbox writable set, and create the log
directory alongside the existing LaunchAgents mkdir. WorkingDirectory
stays on INSTALL_DIR since chdir is not sandbox-gated.
…REAM_HOME unset
Running `bash /path/to/install/dream-macos.sh status` from a non-default
install without DREAM_HOME set would error with
`Dream Server not found at $HOME/dream-server`, even though the script
itself was physically inside the install. External-drive installs,
custom Homebrew prefixes, CI automation and any launchd/cron invocation
by absolute path all hit this.
Resolve it by teaching `resolve_install_dir()` a new `DREAM_SCRIPT_HINT`
tier between the DREAM_HOME and DS_INSTALL_DIR branches, guarded by a
`.env` sentinel file at the hinted root so that PATH symlinks
(e.g. /usr/local/bin) or scratch copies never false-positive.
`dream-macos.sh` exports `DREAM_SCRIPT_HINT="$SCRIPT_DIR"` before sourcing
`constants.sh`, then unsets it after all sources complete so the hint
does not leak into docker-compose/curl subprocesses spawned later.
While verifying the fix end-to-end, I discovered that
`installers/macos/lib/constants.sh` had a latent off-by-one in its
`path-utils.sh` lookup: `MACOS_SCRIPT_DIR="$(cd ...)/../.."` resolved to
the wrong depth in both source-tree and installed layouts, and the
lookup path then re-appended `installers/lib/path-utils.sh` producing
e.g. `dream-server/installers/installers/lib/path-utils.sh` (source) or
`/Volumes/X/installers/lib/path-utils.sh` (installed) - neither exists.
The `if` branch never fired; `resolve_install_dir()` was never actually
called from `dream-macos.sh`, and the ELSE fallback
`DS_INSTALL_DIR="${DREAM_HOME:-$HOME/dream-server}"` was the only live
code path. Without fixing this, the new `DREAM_SCRIPT_HINT` tier would
have been dead on both layouts. Replace the broken single-path lookup
with a two-candidate loop (`../../lib/path-utils.sh` for source tree,
`../installers/lib/path-utils.sh` for installed) and drop the
`MACOS_SCRIPT_DIR` variable (no other consumers after grep).
BATS coverage in `tests/bats-tests/path-utils.bats` gets two new cases
for the new tier (hint + sentinel present, hint + sentinel absent) and
a `setup`/`teardown` that clears `DREAM_SCRIPT_HINT` alongside the
existing env vars so the file stays isolation-safe.
Closes yasinBursali#339
Two tests in dashboard-api's test_updates.py were flaky because their mocks did not intercept the HTTP client the production code actually uses. test_get_version_with_mock_github patched urllib.request.urlopen, but routers/updates.py::_refresh_release_cache uses httpx.AsyncClient, so the patch targeted nothing. The test only passed when a module-level _version_cache global had already been populated by a prior test in the same pytest session. On a fresh cache with a slow CI runner the 1.25 s shield timeout in get_version fired, _build_version_result returned latest=None, and the assertion "None == '2.0.0'" failed. test_get_releases_manifest_authenticated had no mock at all and hit live api.github.com/.../releases. When GitHub rate-limited the request it returned a JSON error object rather than a list; the route's list comprehension then iterated dict keys (strings) and called .get(...) on a string, raising AttributeError. Both are rewritten to use the AsyncMock pattern already established by test_releases_manifest_with_mocked_github in the same file: build an httpx.AsyncClient mock with __aenter__/__aexit__ set, an async get() method returning a MagicMock whose .json() returns the fixture payload, and patch the client at routers.updates.httpx.AsyncClient so the point of use is intercepted. test_get_version_with_mock_github additionally clears _version_cache and _version_refresh_task via monkeypatch so the mocked path is exercised rather than a leftover payload. No production code changed. The latent production bug in get_release_manifest (missing list-vs-dict guard on the GitHub response) is filed as a separate fork issue rather than bundled in. Closes yasinBursali#326
Langfuse was the only optional built-in extension missing from the
installer feature menu. All LANGFUSE_* secrets are already generated
unconditionally by installers/phases/06-directories.sh, the extension
ships as compose.yaml.disabled, and .env.schema.json registers every
LANGFUSE_* key — but there was no user-facing way to opt in at install
time. Users had to run `dream enable langfuse` post-install, which is
inconsistent with every other optional extension.
Add langfuse to all three installers' feature selection:
Linux (install-core.sh + installers/lib/ui.sh + phases/03-features.sh):
- ENABLE_LANGFUSE=false default, --langfuse / --no-langfuse flags,
langfuse in --all expansion (--no-langfuse after --all wins via
case-loop order, matching the existing comfyui/dreamforge pattern).
- show_install_menu: Full Stack enables it, Core Only disables it.
- 03-features.sh Custom menu: [y/N] opt-in prompt matching openclaw.
- New langfuse compose-rename block mirroring comfyui/dreamforge.
macOS (installers/macos/install-macos.sh + macos/lib/env-generator.sh):
- ENABLE_LANGFUSE=false + NO_LANGFUSE_EXPLICIT=false defaults,
--langfuse / --no-langfuse flags. Because macOS post-processes --all
outside the case loop, the override uses order-insensitive tracking:
`$NO_LANGFUSE_EXPLICIT || ENABLE_LANGFUSE=true` after the --all fan-out.
- Features info_box, interactive Custom menu prompt, dry-run phase
message, SKIP case entry in the compose-flags assembly loop, and a
compose-rename block before the extension-discovery loop.
- env-generator.sh heredoc propagates ENABLE_LANGFUSE to LANGFUSE_ENABLED.
Windows (installers/windows/*):
- install-windows.ps1: -Langfuse / -NoLangfuse switches + phase context.
- phases/03-features.ps1: $enableLangfuse default is
`($langfuseFlag -or $allFlag) -and (-not $noLangfuseFlag)`
(order-insensitive). Full Stack enables, Core Only disables, Custom
branch prompts. Summary line added.
- phases/06-directories.ps1: passes -EnableLangfuse to New-DreamEnv.
- lib/env-generator.ps1: New-DreamEnv gains a [bool]$EnableLangfuse
parameter; LANGFUSE_ENABLED defaults to that value, falling back to
Get-EnvOrNew so manual post-install edits survive re-install.
installers/phases/06-directories.sh gets a one-line fix: the
LANGFUSE_ENABLED default in the generated .env changes from a hardcoded
"false" literal to `${ENABLE_LANGFUSE:-false}`, so the install-time flag
actually reaches the container. Without this, --langfuse would be a
no-op on Linux — .env would still ship LANGFUSE_ENABLED=false.
Bundled bonus fix: installers/phases/03-features.sh wraps its three
extension compose-rename blocks (comfyui, dreamforge, langfuse) in a
single `if ! $DRY_RUN` gate. The pre-existing comfyui and dreamforge
blocks were un-gated and would rename compose files during dry-run,
leaking source-tree mutations into preview invocations. Since the new
langfuse block inherits the same shape, fixing all three at once keeps
the dry-run contract honest with zero additional churn.
Full Stack enables Langfuse even though the issue author's suggestion
was "default OFF for all tiers including Full Stack": the Full Stack UI
label says "all features enabled", so leaving langfuse silently off
there would contradict the label. Non-interactive / scripted installs
remain conservative — the CLI default is off and requires --langfuse,
--all, or the Custom menu to opt in.
Closes yasinBursali#327
installers/macos/lib/env-generator.sh unconditionally writes HOST_RAM_GB=<unified memory GB> to the .env of every Apple Silicon install. .env.schema.json had no HOST_RAM_GB entry, so the schema-aware validator in dashboard-api main.py (_handle_env_update plus its api_settings_env_save / api_settings_env_apply proxies) rejected every PUT /api/settings/env with 503 "Unknown key: HOST_RAM_GB". On macOS that broke the dashboard Settings panel completely — users could not save anything from the UI on a fresh install. Register HOST_RAM_GB as an optional integer property in .env.schema.json (minimum 1, maximum 1024 as forward-looking bounds) and add a commented-out example in .env.example next to the other hardware-section keys so _render_env_from_values walks it in the natural position on rebuild. The value is actively consumed on Apple Silicon: docker-compose.base.yml and installers/macos/docker-compose.macos.yml pass it through to the llama-server container env, and dashboard-api routers/features.py reads it as the Apple Silicon VRAM fallback for tier gating. The schema gap was the only missing link; every other consumer already handled the value correctly. Audit: grep 'KEY=' installers/macos/lib/env-generator.sh cross-referenced against schema properties. HOST_RAM_GB was the only missing entry. HOST_GPU_CORES and HOST_CHIP are not written by the generator (per project convention) and stay out of the schema. Closes yasinBursali#337
…concile with filesystem get_bootstrap_status() checked only for status == "complete" to return active=False. A failed download left bootstrap-status.json with status="failed", which fell through to the active=True return path. The dashboard then rendered a permanent stale "Downloading Full Model — 0.0%" banner with no way for the user to dismiss it. Part 1: extend the terminal-status check to cover "failed", "cancelled", and "error" so any non-in-progress state returns inactive. "cancelled" and "error" are not currently produced by the download worker but are reserved for forward-compatibility. Part 2: filesystem reconciliation. After the terminal-status check, verify whether the target model file is already present on disk with non-zero size. If it is, return inactive regardless of what the status record says — covers stale "downloading" entries left by a crash or a parallel download path (e.g. the dashboard Models page downloading the same model concurrently). Two guards protect the reconciliation: - Skip during status="verifying" because the file has been renamed into place but SHA256 verification is still running. Returning inactive here would suppress the banner one tick too early and hide a subsequent verification failure. - Path containment via resolve() + is_relative_to() so a corrupted or malicious model name cannot escape the models directory. Four unit tests added to TestGetBootstrapStatus covering the new code paths: failed status, filesystem reconciliation, verifying-skip, and path traversal rejection. Closes yasinBursali#329
useSystemStatus guards its polling loop with `if (document.hidden)
return` to save CPU/network when the tab is backgrounded. But that
guard fires before the very first fetch, so a dashboard opened in a
background tab (multi-monitor, restored browser session, MCP/Playwright
automation, secondary-monitor drag) gets permanently stuck on the
loading skeleton ("Linking modules... reading telemetry...", "Services
Online: 0/0") until the user happens to focus the tab and the
visibilitychange listener triggers the first fetch.
Add a hasInitialData ref that starts false and gates the hidden-tab
guard: `if (document.hidden && hasInitialData.current) return`. The
initial fetch always runs regardless of tab visibility. After the first
successful response, hasInitialData flips to true and the hidden-tab
guard engages for all subsequent polls — preserving the original
CPU/bandwidth savings for the common case (user backgrounds a tab
that already has data).
The loading skeleton is now guaranteed to resolve to either real data
or an error state, never stuck indefinitely.
Closes yasinBursali#330
…kens PR Light-Heart-Labs#895 replaced the hardcoded bg-[#0d0b12]/95 on the Dashboard feature-card info tooltip with bg-theme-card/95 to respect the active theme. But tailwind.config.js declared theme colors as bare var() references without the <alpha-value> placeholder that Tailwind's opacity-modifier syntax requires, so bg-theme-card/95 never compiled — the tooltip rendered transparent on every theme. This combined PR ships both the class-name swap (Dashboard.jsx) and the Tailwind config + CSS variable format conversion that makes it work: - tailwind.config.js: all 11 theme color keys use rgb(var(--theme-X) / <alpha-value>) for alpha support - src/index.css: 44 color vars (11 tokens × 4 themes) converted from hex to space-separated RGB triplets; 12 raw CSS consumers wrapped with rgb() for the new format - src/pages/Dashboard.jsx: bg-[#0d0b12]/95 → bg-theme-card/95 Also fixes 3 pre-existing broken classes: bg-theme-bg/50, bg-theme-bg/80, bg-theme-text-muted/45. Replaces: Light-Heart-Labs#895, Light-Heart-Labs#928 Closes yasinBursali#336
Combines two fixes to the bootstrap-upgrade and compose overlay system: 1. Bootstrap-upgrade hardening (Light-Heart-Labs#898): filename arg validation, docker group membership detection, JSON body escaping for the host-agent model-activate call, and 11-services.sh COMPOSE_ARGS alignment. 2. macOS compose overlay routing (Light-Heart-Labs#918): the bootstrap-upgrade.sh apple) fallback case arm now branches on uname -s to select installers/macos/docker-compose.macos.yml on Darwin hosts instead of the top-level docker-compose.apple.yml (which is for Linux-apple backend / Lemonade). Also updates classify-hardware.sh OVERLAY_MAP, hardware-classes.json apple_silicon compose_overlays, and manifest.json canonical list. Replaces: Light-Heart-Labs#898, Light-Heart-Labs#918 Closes yasinBursali#325
…onse When GitHub returns a rate-limit dict instead of a release list, the list comprehension crashes with AttributeError. Add isinstance check that raises httpx.HTTPError, caught by the existing fallback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Core Only case in show_install_menu was missing ENABLE_DREAMFORGE=false, causing DreamForge to stay enabled despite the "lean and fast" promise. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add commented-out DREAM_AGENT_BIND entry to .env.example explaining the platform difference: macOS/Windows default to 127.0.0.1 (safe), Linux defaults to 0.0.0.0 (required for Docker bridge reachability). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- test-overlay-map-coherence.sh: validates classify-hardware.sh OVERLAY_MAP matches hardware-classes.json compose_overlays for all 10 classes - test-plist-log-paths.sh: validates launchd plist log paths use \$HOME/Library/Logs/DreamServer/ (not \$INSTALL_DIR) - Both registered in Makefile test target Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Enable disable toggle for error/stopped extensions (unblocks uninstall) - Show "API service" badge instead of port link for headless extensions (embeddings, tts, whisper, privacy-shield) - Make console/logs button more prominent: larger icon, text label, state-dependent colors (red for error, amber for installing/stopped) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The langfuse-minio-init container referenced minio/mc:RELEASE.2025-09-07T16-13-09Z which does not exist on Docker Hub (the September release was only published for minio/minio, not minio/mc). This causes `docker compose up` to fail for the entire stack on fresh installs with --all or --langfuse. Pin to RELEASE.2025-08-13T08-35-41Z — the latest published minio/mc tag. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…devtools-fixes fix(07-devtools): opencode.json handling + host-agent service restart
…ons-compose-corrections fix(extensions): compose corrections for baserow, aider, continue
…tstrap-upgrade-hardening fix(bootstrap-upgrade): hardening + macOS compose overlay routing
…-compose-macos-overlay fix(resolve-compose-stack): select macOS overlay on Darwin hosts
…a-cpu-limit Auto-detect llama-server CPU limits from Docker availability
The Windows installer never ported the host agent setup from Linux Phase 07. After install, the dashboard showed "Host agent is offline" and extension management was broken. - Add agent constants to constants.ps1 (port, PID file, log, health URL, task name) - Start agent in 07-devtools.ps1 with reinstall handling and scheduled task registration for login persistence - Add Invoke-Agent function to dream.ps1 with status/start/stop/restart/logs - Integrate agent into dream.ps1 start/stop/status commands - Prepend Docker bin to PATH in agent launch to handle fresh Docker installs Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…dows-host-agent-startup fix(windows): start and persist host agent after install
…T, LLAMA_CPP_REF) The installer phase 06 generates these three AMD-specific variables for Strix Halo builds, but they were absent from .env.schema.json. The schema validator treats unknown keys as errors, causing installation to fail on AMD Strix Halo hardware. Fixes Light-Heart-Labs#957
…rix-halo-env-schema Fix/amd strix halo env schema
…tests-for-docker-and-health-phases test: add BATS tests for docker and health phase scripts
…acos-script-dir-autodetect fix(dream-macos): auto-detect install dir from script location when DREAM_HOME unset
…spy-auth-docs-drift fix(token-spy): stop forwarding proxy auth upstream and align shipped docs
…env-example-with-installer docs: sync .env.example with installer-generated variables
…nstaller-paths fix(macos-installer): dynamic launchd PATH + extensions-lib source
…se-install-menu feat(installer): add --langfuse flag and Custom menu prompt for langfuse
…-plist-early-unload fix(macos-installer): unload stale LaunchAgents before compose-up
Services were hardcoded to bind 127.0.0.1, making DreamServer
inaccessible from other machines on the LAN. The installer also
printed a misleading LAN URL that could never work.
- Add BIND_ADDRESS env var (enum: 127.0.0.1 or 0.0.0.0, default 127.0.0.1)
- Substitute ${BIND_ADDRESS:-127.0.0.1} into all 23 compose port bindings
- Add --lan flag to install-core.sh (sets BIND_ADDRESS=0.0.0.0)
- Add -Lan flag to Windows installer (install.ps1 + install-windows.ps1)
- Write BIND_ADDRESS to .env via Phase 06 (Linux) and env-generator (Windows)
- Add to .env.schema.json with enum constraint for dashboard dropdown
- Add to dashboard-api _MANUAL_RESTART_KEYS (requires full stack restart)
- Fix Phase 13 summary: only show LAN URL when BIND_ADDRESS=0.0.0.0
- Fix Windows Write-SuccessCard: same conditional LAN URL logic
- Update SECURITY.md with Quick LAN Access section
Three paths to enable LAN access:
1. Install: ./install.sh --lan
2. Dashboard: Settings → BIND_ADDRESS → 0.0.0.0 → save → dream restart
3. Manual: Set BIND_ADDRESS=0.0.0.0 in .env → dream restart
Default behavior unchanged — existing installs stay on 127.0.0.1.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…nfigurable-bind-address feat: configurable BIND_ADDRESS for LAN access on headless servers
Lightheartdevs
force-pushed
the
fix/dir-size-gb-ttl-caching
branch
from
b7fa750 to
99dc8a0
Compare
Sensitive Files DetectedTrigger: Security-sensitive files detected: dream-server/installers/ Files flagged: Extra human review is recommended for this PR. Claude Code Review | Sensitive File Detection | ~$1.50 |
boffin-dmytro
force-pushed
the
fix/dir-size-gb-ttl-caching
branch
from
99dc8a0 to
550db99
Compare
Sensitive Files DetectedTrigger: Security-sensitive files detected: dream-server/installers/ Files flagged: Extra human review is recommended for this PR. Claude Code Review | Sensitive File Detection | ~$1.50 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
dir_size_gb()usespath.rglob("*")which recursively walks every file in a directory tree — on large model directories (tens of GB, thousands of files) this blocks the request thread on every callinvalidate_dir_size_cache()and wired it intopurge_extension_dataso the cache stays accurate after mutationsTest plan
/api/services/resourcesmultiple times within 60s — second call should return instantly without re-walking disk/api/extensions/{id}/data— subsequent resource calls should reflect the freed spacedir_size_gb, so no test changes needed)