Reviewing files that changed from the base of the PR and between 5f5d154 and b2c9a9f.

• components/log-viewer-webui/client/src/config/index.ts (1 hunks)
• components/log-viewer-webui/client/src/pages/SearchPage/SearchState/useResultsMetadata.ts (1 hunks)

components/log-viewer-webui/client/src/config/index.ts (1)

1-1:

Details

✅ Verification successful

Verify synchronous availability of imported settings
Ensure that the settings object from ../settings is fully populated when this module executes. If settings.ts loads data asynchronously (e.g., via HTTP), settings.ClpStorageEngine could be undefined at import time, causing downstream errors.

Use the following script to inspect settings.ts and verify whether loading is synchronous or asynchronous:

---

🏁 Script executed:

#!/bin/bash
# Check for async HTTP calls in settings.ts
rg -n "axios.get" -n components/log-viewer-webui/client/src/settings.ts

Length of output: 143

---

🏁 Script executed:

#!/bin/bash
# Inspect how settings is used within the config module
sed -n '1,200p' components/log-viewer-webui/client/src/config/index.ts

Length of output: 519

---

🏁 Script executed:

#!/bin/bash
# Print the contents of settings.ts to inspect export and population logic
sed -n '1,200p' components/log-viewer-webui/client/src/settings.ts

Length of output: 850

---

Confirmed synchronous availability of settings.ClpStorageEngine
The settings.ts module uses a top-level await loadSettings(), so the export isn’t resolved until the HTTP fetch completes. When you import settings in config/index.ts, settings.ClpStorageEngine is guaranteed to be defined—provided your build targets ES modules with top-level‐await support.

components/log-viewer-webui/client/src/pages/SearchPage/SearchState/useResultsMetadata.ts (1)

5-5:

Details

✅ Verification successful

Verify synchronous availability of the injected settings object

The hook dereferences settings immediately after import, but the new settings.ts module (introduced in this PR) reportedly fetches and populates the object asynchronously at app start-up. If that population hasn’t completed by the time this hook runs, settings.MongoDbSearchResultsMetadataCollectionName will be undefined, leading to a runtime error downstream in MongoCollectionSocket.

Please confirm that settings is guaranteed to be fully initialised before any React component renders, or add a defensive guard / loading gate.

---

🏁 Script executed:

#!/bin/bash
# Search for an explicit initialisation routine that ensures settings are ready
# before React mounts.  We expect to find something like `await loadSettings()`
# in the app bootstrap.
rg -n --type ts -e 'loadSettings|initSettings|settingsReady'

Length of output: 273

---

🏁 Script executed:

#!/bin/bash
# Display the top of the settings.ts to inspect if it uses top-level await
sed -n '1,50p' components/log-viewer-webui/client/src/settings.ts

Length of output: 849

---

🏁 Script executed:

#!/bin/bash
# Locate tsconfig.json and show compilerOptions for module/target support
if [[ -f tsconfig.json ]]; then
  echo "=== tsconfig.json ==="
  sed -n '1,200p' tsconfig.json
else
  echo "tsconfig.json not found at root, searching..."
  find . -maxdepth 3 -type f -name 'tsconfig.json'
fi

echo
# Inspect package.json to determine bundler and script setup
if [[ -f package.json ]]; then
  echo "=== package.json (first 200 lines) ==="
  sed -n '1,200p' package.json
fi

echo
# Find common bundler configuration files
echo "=== Bundler config files ==="
find . -maxdepth 3 -type f \( -name 'webpack.config.js' -o -name 'vite.config.js' -o -name 'rollup.config.js' \)

Length of output: 392

---

🏁 Script executed:

#!/bin/bash
# Search for tsconfig.json, package.json, and bundler configs anywhere in the repo
echo "=== tsconfig.json files ==="
find . -type f -name 'tsconfig.json'

echo
echo "=== package.json files ==="
find . -type f -name 'package.json'

echo
echo "=== Bundler configuration files ==="
find . -type f \( -name 'webpack.config.js' -o -name 'vite.config.js' -o -name 'rollup.config.js' \)

Length of output: 762

---

🏁 Script executed:

#!/bin/bash
# Inspect the client-side TypeScript configuration for module/target settings
echo "=== components/log-viewer-webui/client/tsconfig.json ==="
sed -n '1,200p' components/log-viewer-webui/client/tsconfig.json

echo
# Inspect the client-side package.json for build tool or scripts
echo "=== components/log-viewer-webui/client/package.json ==="
sed -n '1,200p' components/log-viewer-webui/client/package.json

Length of output: 1945

---

🏁 Script executed:

#!/bin/bash
# Inspect the client-side application TypeScript config for module and target settings
sed -n '1,200p' components/log-viewer-webui/client/tsconfig/tsconfig.app.json

Length of output: 750

---

Settings import is safe—no guard needed
The settings.ts module employs a top-level await (const settings: Settings = await loadSettings();) and your client TS config (target: "ES2022", module: "ESNext") together with Vite’s bundler preserves this behaviour. Any module importing settings will not execute until the JSON fetch completes. It’s therefore safe to dereference settings.MongoDbSearchResultsMetadataCollectionName immediately in the hook.