Skip to content

Conversation

@igotstatik
Copy link
Contributor

@igotstatik igotstatik commented Jul 17, 2025

feat: Add Open WebUI integration with Super Protocol tunnel client

│ - Add Open WebUI as git submodule for AI chat interface
│ - Implement TypeScript wrapper with tunnel client integration
│ - Configure Docker setup with multi-stage build for frontend and backend
│ - Add Ollama integration for local LLM inference
│ - Set up proper data directory structure at /opt/app/data
│ - Configure SSL/TLS support for secure connections
│ - Add environment variables for blockchain and tunnel configuration
│ - Optimize Dockerfile by removing unnecessary build checks
│ - Add comprehensive .gitignore for certificates, build artifacts, and user data

Summary by CodeRabbit

  • New Features

    • Added new Dia TTS Server and Open WebUI solutions, including configuration files, Docker and Docker Compose support, and integration with blockchain parameters.
    • Introduced example environment variable templates for both solutions.
    • Integrated submodules for Dia TTS Server and Open WebUI components.
  • Chores

    • Updated ignore files to exclude sensitive and build-related files from version control.
    • Added TypeScript configuration and project metadata files for both solutions.
  • Documentation

    • Removed the main README file from the repository.

root and others added 21 commits June 23, 2025 15:54
- Add Dia-TTS-Server submodule with package.json
- Complete TypeScript integration layer
- Docker container ready for deployment
- Scripts for Super Protocol tunneling

Ready for deployment in Super Protocol TEE
- TypeScript integration layer with HTTPS support
- Docker container configuration
- Super Protocol deployment scripts
- Build configuration and dependencies
- Working integration ready for deployment

Note: dia-tts-server source will be added separately
- Python source files for TTS server
- UI components and configuration
- Requirements and documentation
- Exclude heavy model files and cache (3GB+)

Models will be downloaded during Docker build
- Keep only TypeScript source files (.ts)
- Compiled .js files generated during build
- Added build artifacts to .gitignore
- Delete all .js files from src/ directory
- These are build artifacts and should not be in git
- Keep only TypeScript source files (.ts)
- Files will be generated during npm run build
- Remove local dia-tts-server directory copy
- Add proper git submodule pointing to github.com/devnen/Dia-TTS-Server.git
- Clean up old submodule references
- This allows proper version tracking and easier updates
Dia tts solution - tunnel client integration
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jul 17, 2025

Walkthrough

This update introduces two new submodules, "Dia TTS Server" and "open_webui," each with their own Docker, TypeScript, and configuration setups. Both projects add environment templates, ignore files, build scripts, and TypeScript code for configuration, logging, and server orchestration. The root .gitignore and .gitmodules are updated, and the main README is removed.

Changes

Files / Groups Change Summary
.gitignore, .gitmodules Add CLAUDE.md to .gitignore; introduce two new submodules for Dia TTS Server and open_webui.
readme.md Remove repository README file.
Dia TTS Server/* (Dockerfile, .env.example, etc.) Add Dia TTS Server project: Docker, env templates, ignore files, TypeScript config, and source code.
Dia TTS Server/dia-tts-server Add submodule reference to external Dia TTS Server repository.
open_webui/* (Dockerfile, .env.example, etc.) Add open_webui project: Docker, env templates, ignore files, TypeScript config, and source code.
open_webui/open-webui Add submodule reference to external open-webui repository.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant TunnelClient
    participant Server (Node.js)
    participant PythonBackend

    User->>TunnelClient: Start application
    TunnelClient->>Server (Node.js): Initialize with config, logger, env
    Server (Node.js)->>PythonBackend: Spawn backend (uvicorn / Open WebUI)
    PythonBackend-->>Server (Node.js): Ready signal / process running
    Server (Node.js)-->>TunnelClient: Service available
    TunnelClient-->>User: Tunnel client operational
Loading

Poem

(\(\
( -.-)
o_(")(")

Two new submodules hop in with glee,
Docker and TypeScript as far as I see.
Configs and loggers, all in a row—
Tunnels and servers ready to go!
The README is gone, but the code is bright,
Rabbits rejoice, for all feels right!

✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 10

♻️ Duplicate comments (2)
Dia TTS Server/src/config.ts (2)

13-17: Remove unnecessary type casting for environment variables.

Same issue as in the open_webui config - the type casting is redundant.


23-23: Improve error handling for numeric parsing.

Same Number.parseInt() issue as in the open_webui config - potential NaN runtime errors.

🧹 Nitpick comments (30)
.gitignore (2)

113-114: No objections to ignoring CLAUDE.md, but watch for file-name drift.

If CLAUDE.md is intentionally generated or used only for local experimentation, ignoring it here is sensible.
However, if the filename ever changes (e.g., claude.md, CLAUDE-notes.md) you’ll need to keep this rule in sync. Consider a pattern (CLAUDE*.md) if multiple variants are expected.


1-106: Duplicate .idea entry – keep the list DRY.

.idea appears twice (lines 3 and 105). While harmless, removing the duplicate keeps the ignore list concise and avoids future merge conflicts.

-# IDE/Code edotors
-.devcontainer
-.idea
+# IDE/Code editors / devcontainer
+.devcontainer
Dia TTS Server/tsconfig.build.json (1)

2-4: Consider declaring an explicit include list for clarity

While TypeScript will pick up all non-excluded files by default, adding an include clause makes intent crystal-clear (and prevents stray files in future from being compiled unintentionally).

   "extends": "./tsconfig.json",
   "exclude": ["node_modules", "dist", "**/*.test.ts"],
+  "include": ["src/**/*.ts"]
Dia TTS Server/dia-tts-server (1)

1-1: Consider renaming the submodule path to avoid spaces

Having a space in the directory name (Dia TTS Server/…) can break Docker build-args, shell scripts, CI steps, and any tooling that forgets to quote paths. It’s safer to use kebab-case or snake_case (e.g. dia-tts-server/) to minimise cross-platform pitfalls.

Please verify:

  1. All references in Dockerfiles, docker-compose, TypeScript imports, and CI scripts correctly quote this path.
  2. .gitmodules contains the exact same path (spaces included); mismatches will break git submodule update.
open_webui/tsconfig.build.json (1)

2-3: Consider tightening the build-only config.

tsconfig.build.json is meant for production compilation. Omitting an "include" (or an explicit "files") section means every .ts file not under exclude is compiled, which can pull in benches, scripts, etc. that you probably don’t want in dist.

 {
   "extends": "./tsconfig.json",
+  "include": ["src/**/*.ts"],
   "exclude": ["node_modules", "dist", "**/*.test.ts"]
 }

Keeps the build scope predictable and shortens compile time.

Dia TTS Server/.env.example (1)

1-4: Replace concrete values with placeholders in example files.

Example .env files should guide users without hard-coding project-specific values. Using a real RPC URL and contract address invites accidental misuse in other environments.

-LOG_LEVEL=trace
-BLOCKCHAIN_URL=http://127.0.0.1:8545
-BLOCKCHAIN_CONTRACT_ADDRESS=0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0
+LOG_LEVEL=trace
+# e.g. http://127.0.0.1:8545
+BLOCKCHAIN_URL=<BLOCKCHAIN_RPC_URL>
+# e.g. 0x0000000000000000000000000000000000000000
+BLOCKCHAIN_CONTRACT_ADDRESS=<CONTRACT_ADDRESS>

Helps prevent misconfiguration and clarifies intent.

open_webui/.env.example (1)

1-3: Align ordering & add trailing newline for lint clean-ness.

dotenv-linter warnings are harmless but easy to silence:

-BLOCKCHAIN_URL=http://127.0.0.1:8545
-BLOCKCHAIN_CONTRACT_ADDRESS=0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0
+BLOCKCHAIN_CONTRACT_ADDRESS=<CONTRACT_ADDRESS>
+BLOCKCHAIN_URL=http://127.0.0.1:8545
+

(Not critical, purely cosmetic.)

Dia TTS Server/src/logger.ts (1)

4-9: Expose both root and app-scoped loggers for flexibility.

pino(pinoConfig).child({ … }) already yields a child logger, yet the symbol is named rootLogger. If other modules later call pino() directly, log meta will diverge.

-const pinoConfig = { level: config.logLevel };
-
-export const rootLogger = pino(pinoConfig).child({
-  app: config.appName,
-  version: config.appVersion,
-});
+const pinoConfig = { level: config.logLevel };
+
+export const baseLogger = pino(pinoConfig);
+export const appLogger  = baseLogger.child({
+  app: config.appName,
+  version: config.appVersion,
+});

Retains a true root while still providing enriched logs.

Dia TTS Server/.dockerignore (1)

1-3: Double-check dist exclusion vs. multi-stage build.

The Dockerfile appears to compile TS inside the container, so ignoring dist is fine. If you ever switch to “compile locally then copy”, this rule will silently break the image. Pin a comment for future maintainers?

-dist
+# dist – generated in the build stage inside the image
+dist

Tiny doc helps avoid head-scratching later.

Dia TTS Server/src/env-utils.ts (1)

1-7: LGTM with a minor consideration for edge cases.

The function logic is correct and follows best practices for environment variable validation. The error message is clear and descriptive.

Consider whether empty strings should be treated as valid values for some use cases:

-  if (!value) {
+  if (!value || value.trim() === '') {

This change would reject empty strings and whitespace-only values, which might be more appropriate for most environment variables.

open_webui/src/env-utils.ts (1)

1-7: LGTM! Note potential code duplication.

The function implementation is correct and follows the same pattern as Dia TTS Server/src/env-utils.ts.

Consider extracting this common utility to a shared library in future iterations to avoid code duplication between projects, especially if both projects are maintained together.

open_webui/.gitignore (1)

1-14: Clean up duplicate entries in .gitignore.

The ignore patterns are appropriate for excluding certificates, build artifacts, dependencies, and user data. However, there are duplicate entries that should be removed:

 certs/*
 tunnel-client-certs/*
 # TypeScript build artifacts
 src/*.js
 src/*.js.map
 dist/
 node_modules/
 
 # Open WebUI data directory (contains user data, databases, uploads)
 open-webui-data/
-
-# Build artifacts
-dist/
-node_modules/

The patterns correctly exclude sensitive and generated files from version control.

Dia TTS Server/.gitignore (1)

24-28: Ignore patterns only cover root-level JS artifacts

src/*.js and src/*.js.map skip JavaScript emitted inside nested folders (src/utils/foo.js, etc.). TypeScript’s compiler often mirrors the source tree, so these files may leak into the repo.

- src/*.js
- src/*.js.map
+ src/**/*.js
+ src/**/*.js.map

The same applies to dist/; keeping it already covers compiled code, but tightening the src/** pattern prevents accidental commits during local ts-node transpilation.

Dia TTS Server/docker-compose.yml (1)

3-17: Harden the service definition (restart policy, non-root user, env-file)

Current compose spec works but misses a few production-grade defaults:

  1. Add restart: unless-stopped (or on-failure) to auto-recover the container.
  2. Run the service as a non-root UID/GID to reduce blast radius (user: "1000:1000").
  3. Instead of inlining model vars, reference an .env or env_file to keep compose clean and avoid accidental commit of secrets.

Example patch:

   dia-tts-server:
@@
     volumes:
       - ./dia-tts-server/model_cache:/sp/inputs/input-0001
+    restart: unless-stopped
+    user: "1000:1000"
-    environment:
-      - DIA_MODEL_REPO_ID=ttj/dia-1.6b-safetensors
-      - DIA_MODEL_CONFIG_FILENAME=config.json
-      - DIA_MODEL_WEIGHTS_FILENAME=dia-v0_1_bf16.safetensors
+    env_file:
+      - .env
open_webui/tsconfig.json (1)

1-20: Consider enabling faster incremental builds and explicit module resolution

tsc can feel sluggish in multi-service monorepos. Two small compiler-option tweaks improve DX without changing output:

{
  "compilerOptions": {
+   "incremental": true,
+   "tsBuildInfoFile": "./dist/.tsbuildinfo",
+   "moduleResolution": "node",
    ...
  }
}

incremental stores build info in .tsbuildinfo for ≈ 3-5× faster subsequent compiles, and explicit "moduleResolution": "node" removes ambiguity when Node upgrades the default.

Dia TTS Server/package.json (1)

16-22: Pin exact dependency versions to avoid unexpected breakages

Using caret (^) ranges for core Super Protocol libs means any future minor/major release can silently introduce breaking changes. In production-grade images, prefer exact versions (or at least tilde ranges) and update intentionally.

-    "@super-protocol/sdk-js": "^3.11.5",
+    "@super-protocol/sdk-js": "3.11.5",

(Apply to all deps listed here.)

Dia TTS Server/src/server-config.ts (1)

11-17: Resolve paths from project root and pass radix explicitly

path.join(__dirname, …) will resolve relative to the compiled dist directory at runtime, not the project root. That may break certificate discovery when the code is transpiled.
Also, parseInt without a radix is discouraged.

-      privateKeyFilePath: path.join(__dirname, config.certPrivateKeyFileName),
-      certificateFilePath: path.join(__dirname, config.certFileName),
-      port: Number.parseInt(getEnvValueOrFail('HTTPS_PORT')),
+      privateKeyFilePath: path.resolve(__dirname, '..', config.certPrivateKeyFileName),
+      certificateFilePath: path.resolve(__dirname, '..', config.certFileName),
+      port: Number.parseInt(getEnvValueOrFail('HTTPS_PORT'), 10),
open_webui/docker-compose.yml (1)

25-26: Add a trailing newline and quote multiline secrets

YAML-lint flags the missing EOF newline. Also, raw TLS_KEY / TLS_CERT lines containing literal line-breaks require quoting; using dummy placeholders now is fine, but quote them to avoid parse surprises.

-      - TLS_KEY=dummy_key
-      - TLS_CERT=dummy_cert
+      - TLS_KEY="dummy_key"
+      - TLS_CERT="dummy_cert"
+
open_webui/package.json (1)

16-22: Lock dependency versions to deterministic builds

Replicate the pinning advice given for the Dia-TTS package to keep Open WebUI images reproducible.

open_webui/src/server-config.ts (1)

11-17: Same path & radix concerns as Dia-TTS

Consider the analogous fix to ensure certificates resolve correctly after transpilation and avoid implicit-radix parseInt.

open_webui/src/index.ts (1)

17-41: Verify tunnel client configuration and error handling.

The tunnel client initialization logic looks correct, but consider adding validation for the configuration parameters before creating the TunnelClient instance.

Consider adding configuration validation:

+ if (!tunnelsConfiguration) {
+   throw new Error('Tunnels configuration is required');
+ }
+ 
+ if (!domainConfigs.length) {
+   throw new Error('No domain configurations found');
+ }

  const options: TunnelClientOptions = {
    logger: rootLogger,
    applicationPort: config.clientServerPort,
    localServerStartTimeout: config.localServerStartTimeoutMs,
  };
open_webui/src/server.ts (2)

1-10: Remove unused import and unclear comment.

The parentPort import is unused, and the comment about unchanged code is unclear and potentially misleading.

- import { parentPort } from 'worker_threads';
- // ... (код terminationHandler и parentPort остается без изменений) ...

20-35: Consider improving Ollama startup reliability.

The hardcoded 3-second delay and detached mode may not be the most reliable approach for process management.

Consider implementing a more robust health check instead of a hardcoded delay:

- // Даем Ollama пару секунд на запуск
- await new Promise(resolve => setTimeout(resolve, 3000));
+ // Wait for Ollama to be ready
+ const waitForOllama = async (maxRetries = 10) => {
+   for (let i = 0; i < maxRetries; i++) {
+     try {
+       const response = await fetch('http://localhost:11434/api/version');
+       if (response.ok) return;
+     } catch (error) {
+       // Ollama not ready yet
+     }
+     await new Promise(resolve => setTimeout(resolve, 1000));
+   }
+   throw new Error('Ollama failed to start within timeout');
+ };
+ await waitForOllama();
Dia TTS Server/src/server.ts (1)

33-47: Verify hardcoded model cache path.

The hardcoded DIA_MODEL_CACHE_PATH may not be flexible for different deployment environments.

Consider making the model cache path configurable:

    env: {
      ...process.env,
-     DIA_MODEL_CACHE_PATH: '/sp/inputs/input-0001'
+     DIA_MODEL_CACHE_PATH: process.env.DIA_MODEL_CACHE_PATH || '/sp/inputs/input-0001'
    },
Dia TTS Server/Dockerfile (1)

20-24: Consider security implications of curl piping to bash.

While functional, piping curl output directly to bash poses security risks. Consider using package managers when possible.

For better security, consider using a multi-step approach:

- RUN apt-get update && apt-get install -y curl \
-     && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
-     && apt-get install -y nodejs git git-lfs build-essential libgl1-mesa-glx libsndfile1 ffmpeg \
-     && apt-get clean && rm -rf /var/lib/apt/lists/*
+ RUN apt-get update && apt-get install -y curl gnupg \
+     && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /usr/share/keyrings/nodesource.gpg \
+     && echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x nodistro main" > /etc/apt/sources.list.d/nodesource.list \
+     && apt-get update && apt-get install -y nodejs git git-lfs build-essential libgl1-mesa-glx libsndfile1 ffmpeg \
+     && apt-get clean && rm -rf /var/lib/apt/lists/*
open_webui/Dockerfile (1)

28-32: Security concern with curl piping to bash.

Similar to the Dia TTS Server Dockerfile, piping curl output directly to bash poses security risks.

Consider using a more secure Node.js installation approach:

- RUN apt-get update && apt-get install -y curl \
-     && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
-     && apt-get install -y nodejs git build-essential \
-     && apt-get clean && rm -rf /var/lib/apt/lists/*
+ RUN apt-get update && apt-get install -y curl gnupg \
+     && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /usr/share/keyrings/nodesource.gpg \
+     && echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x nodistro main" > /etc/apt/sources.list.d/nodesource.list \
+     && apt-get update && apt-get install -y nodejs git build-essential \
+     && apt-get clean && rm -rf /var/lib/apt/lists/*
open_webui/src/config.ts (3)

13-13: Remove unnecessary type casting.

The type casting (process.env.LOG_LEVEL as string) is redundant since process.env values are already string | undefined.

- logLevel: (process.env.LOG_LEVEL as string) || 'trace',
+ logLevel: process.env.LOG_LEVEL || 'trace',

14-17: Remove unnecessary type casting for environment variables.

The type casting (process.env.* as string) is redundant since process.env values are already string | undefined.

- inputDataFolder: (process.env.INPUT_DATA_FOLDER as string) || '/sp/inputs',
- secretsDataFolder: (process.env.SECRETS_DATA_FOLDER as string) || '/sp/secrets',
- certFileName: (process.env.CERT_FILE_NAME as string) || 'certificate.crt',
- certPrivateKeyFileName: (process.env.CERT_PRIVATE_KEY_FILE_NAME as string) || 'private.pem',
+ inputDataFolder: process.env.INPUT_DATA_FOLDER || '/sp/inputs',
+ secretsDataFolder: process.env.SECRETS_DATA_FOLDER || '/sp/secrets',
+ certFileName: process.env.CERT_FILE_NAME || 'certificate.crt',
+ certPrivateKeyFileName: process.env.CERT_PRIVATE_KEY_FILE_NAME || 'private.pem',

19-19: Remove unnecessary type annotation.

The type annotation as number is redundant since 1 is already inferred as a number literal.

- configSearchFolderDepth: 1 as number,
+ configSearchFolderDepth: 1,
Dia TTS Server/src/index.ts (1)

29-32: Potential information leakage in debug logs.

The debug log exposes domain configurations which might contain sensitive information. Consider whether this level of detail should be logged in production environments.

- logger.debug(
-   { domains: domainConfigs.map((config) => config.site.domain) },
-   'Found tunnel client domain configs',
- );
+ logger.debug(
+   { domainCount: domainConfigs.length },
+   'Found tunnel client domain configs',
+ );
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2a94ff4 and ccbf0e0.

⛔ Files ignored due to path filters (2)
  • Dia TTS Server/package-lock.json is excluded by !**/package-lock.json
  • open_webui/package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (34)
  • .gitignore (1 hunks)
  • .gitmodules (1 hunks)
  • Dia TTS Server/.dockerignore (1 hunks)
  • Dia TTS Server/.env.example (1 hunks)
  • Dia TTS Server/.gitignore (1 hunks)
  • Dia TTS Server/Dockerfile (1 hunks)
  • Dia TTS Server/dia-tts-server (1 hunks)
  • Dia TTS Server/docker-compose.yml (1 hunks)
  • Dia TTS Server/package.json (1 hunks)
  • Dia TTS Server/src/config.ts (1 hunks)
  • Dia TTS Server/src/env-utils.ts (1 hunks)
  • Dia TTS Server/src/index.ts (1 hunks)
  • Dia TTS Server/src/logger.ts (1 hunks)
  • Dia TTS Server/src/server-config.ts (1 hunks)
  • Dia TTS Server/src/server.ts (1 hunks)
  • Dia TTS Server/src/types.ts (1 hunks)
  • Dia TTS Server/tsconfig.build.json (1 hunks)
  • Dia TTS Server/tsconfig.json (1 hunks)
  • open_webui/.env.example (1 hunks)
  • open_webui/.gitignore (1 hunks)
  • open_webui/Dockerfile (1 hunks)
  • open_webui/docker-compose.yml (1 hunks)
  • open_webui/open-webui (1 hunks)
  • open_webui/package.json (1 hunks)
  • open_webui/src/config.ts (1 hunks)
  • open_webui/src/env-utils.ts (1 hunks)
  • open_webui/src/index.ts (1 hunks)
  • open_webui/src/logger.ts (1 hunks)
  • open_webui/src/server-config.ts (1 hunks)
  • open_webui/src/server.ts (1 hunks)
  • open_webui/src/types.ts (1 hunks)
  • open_webui/tsconfig.build.json (1 hunks)
  • open_webui/tsconfig.json (1 hunks)
  • readme.md (0 hunks)
💤 Files with no reviewable changes (1)
  • readme.md
🧰 Additional context used
🧠 Learnings (2)
open_webui/open-webui (2)

undefined

<retrieved_learning>
Learnt from: tinovyatkin
PR: #101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
</retrieved_learning>

<retrieved_learning>
Learnt from: tinovyatkin
PR: #101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
</retrieved_learning>

.gitmodules (4)
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:49:17.947Z
Learning: ComfyUI uses versioned tags with "v" prefix (like v0.3.29) in its GitHub repository at comfyanonymous/ComfyUI.
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:49:17.947Z
Learning: ComfyUI Manager uses versioned tags without "v" prefix (like 3.31.12) in its GitHub repository at Comfy-Org/ComfyUI-Manager.
🧬 Code Graph Analysis (7)
Dia TTS Server/src/logger.ts (1)
Dia TTS Server/src/config.ts (1)
  • config (8-24)
open_webui/src/logger.ts (1)
open_webui/src/config.ts (1)
  • config (8-24)
open_webui/src/server-config.ts (3)
open_webui/src/types.ts (1)
  • IServerConfig (1-8)
open_webui/src/config.ts (1)
  • config (8-24)
open_webui/src/env-utils.ts (1)
  • getEnvValueOrFail (1-7)
open_webui/src/server.ts (3)
Petals/src/server-config.ts (1)
  • serverConfig (4-13)
open_webui/src/server-config.ts (1)
  • getServerConfig (8-21)
open_webui/src/logger.ts (1)
  • rootLogger (6-9)
Dia TTS Server/src/server.ts (2)
Dia TTS Server/src/logger.ts (1)
  • rootLogger (6-9)
Dia TTS Server/src/server-config.ts (1)
  • getServerConfig (8-21)
Dia TTS Server/src/config.ts (1)
Dia TTS Server/src/env-utils.ts (1)
  • getEnvValueOrFail (1-7)
open_webui/src/config.ts (1)
open_webui/src/env-utils.ts (1)
  • getEnvValueOrFail (1-7)
🪛 dotenv-linter (3.3.0)
Dia TTS Server/.env.example

[warning] 2-2: [UnorderedKey] The BLOCKCHAIN_URL key should go before the LOG_LEVEL key


[warning] 3-3: [UnorderedKey] The BLOCKCHAIN_CONTRACT_ADDRESS key should go before the BLOCKCHAIN_URL key

open_webui/.env.example

[warning] 2-2: [UnorderedKey] The BLOCKCHAIN_URL key should go before the LOG_LEVEL key


[warning] 3-3: [EndingBlankLine] No blank line at the end of the file


[warning] 3-3: [UnorderedKey] The BLOCKCHAIN_CONTRACT_ADDRESS key should go before the BLOCKCHAIN_URL key

🪛 YAMLlint (1.37.1)
open_webui/docker-compose.yml

[error] 26-26: no new line character at the end of file

(new-line-at-end-of-file)

🔇 Additional comments (28)
Dia TTS Server/tsconfig.build.json (1)

1-4: Build-only tsconfig.build.json looks good

The file cleanly extends the base config and excludes typical non-build artifacts (node_modules, dist, tests). 👍

open_webui/src/logger.ts (1)

1-9: LGTM! Clean logging setup with proper configuration.

The logging implementation follows best practices:

  • Uses pino for structured logging
  • Externalizes configuration to a config module
  • Creates a child logger with useful context (app name and version)
  • Clean and focused implementation

The setup provides a solid foundation for logging throughout the application.

Dia TTS Server/tsconfig.json (1)

1-20: LGTM! Comprehensive TypeScript configuration.

The TypeScript configuration is well-structured and follows best practices:

  • ES2018 target is appropriate for Node.js applications
  • Strict mode enabled for better type safety
  • Proper source and output directory structure
  • Declaration files and source maps enabled for development
  • Correct include/exclude patterns

The configuration provides a solid foundation for TypeScript development.

open_webui/docker-compose.yml (1)

3-13: Container is not exposed to the host; verify that this is intentional

The open-webui service listens on HTTPS_PORT=9000 but no ports: mapping exists. If you intend local browsing/testing, add:

    ports:
      - "9000:9000"

Otherwise confirm that the tunnel client alone will handle ingress.

open_webui/src/index.ts (3)

1-11: Good import organization and module structure.

The imports are well-organized with clear separation between external dependencies and local modules.


13-15: Proper error handling setup.

The global error handlers are correctly set up to ensure graceful shutdown on unhandled rejections, exceptions, and signals.


43-46: Proper error handling for main function execution.

The error handling correctly logs fatal errors and exits with appropriate exit code.

open_webui/src/server.ts (3)

11-18: Good security practices for TLS certificate handling.

The TLS certificates are correctly written with secure permissions (0o600) to prevent unauthorized access.


37-51: Proper uvicorn configuration for HTTPS.

The uvicorn configuration is correct with proper SSL certificates, host binding, and working directory setup.


53-56: Good error handling for startup failures.

The error handling properly logs fatal errors for debugging purposes.

Dia TTS Server/src/server.ts (4)

1-6: Clean and necessary imports.

All imports are being used and appropriately organized.


7-19: Proper process lifecycle management.

The termination handler and signal handling setup provides good process management for graceful shutdown.


21-31: Secure TLS certificate handling.

The TLS certificates are written with appropriate secure permissions (0o600) consistent with security best practices.


49-51: Appropriate error handling for startup failures.

The error handling correctly logs fatal errors for debugging server startup issues.

Dia TTS Server/Dockerfile (5)

1-8: Standard Node.js build stage implementation.

The build stage follows Docker best practices with proper dependency installation and production build.


10-18: Appropriate environment configuration for PyTorch runtime.

The environment variables are properly set for non-interactive installs and Python buffering, which is good for containerized environments.


26-32: Proper artifact copying from builder stage.

The copying of built artifacts and dependencies follows Docker multi-stage build best practices.


34-37: Efficient PyTorch installation with CUDA support.

The PyTorch installation with CUDA-specific wheels and requirements installation is properly configured.


39-42: Appropriate directory structure and entrypoint.

The directory creation and Node.js entrypoint are correctly configured for the application requirements.

open_webui/Dockerfile (6)

1-8: Standard Node.js wrapper build stage.

The build stage follows Docker best practices with proper dependency management and production builds.


10-16: Efficient frontend build stage.

The frontend build stage is well-structured with proper dependency installation and build process.


18-26: Appropriate Python base image and environment setup.

The Python slim base image and environment variables are properly configured for the application requirements.


34-40: Proper Node.js application integration.

The copying of built Node.js artifacts and dependencies is correctly implemented.


42-52: Good integration of Open WebUI components.

The backend copying, Python dependency installation, frontend integration, and Python path setup are well-coordinated.


57-67: Proper directory structure and environment configuration.

The directory creation and Open WebUI environment variables are appropriately configured for the application requirements.

Dia TTS Server/src/index.ts (3)

13-15: Good error handling setup.

The global error handlers for unhandled rejections, uncaught exceptions, and termination signals are properly configured with logging. This ensures graceful shutdown and proper error visibility.


43-46: Proper error handling in main execution.

The catch block appropriately logs fatal errors and exits with a non-zero code, which is good practice for containerized applications.


22-27: Ensure robust error handling around getDomainConfigs
The call to getDomainConfigs (imported from @super-protocol/solution-utils) may throw on network or blockchain failures. Since its implementation lives outside this repo, please verify that either:

  • getDomainConfigs internally catches and wraps connectivity errors with clear messages, or
  • you wrap this call in a try…catch (or use .catch()) here to handle timeouts, bad contract responses, and log/recover appropriately.

• File: Dia TTS Server/src/index.ts, lines 22–27
• Similar calls exist in other services—apply consistent handling.

Comment on lines +9 to +14
[submodule "Dia TTS Server/dia-tts-server"]
path = Dia TTS Server/dia-tts-server
url = https://github.com/devnen/Dia-TTS-Server.git
[submodule "open_webui/open-webui"]
path = open_webui/open-webui
url = https://github.com/open-webui/open-webui.git
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Verification agent

🧩 Analysis chain

Submodule paths with spaces are brittle – rename or quote consistently.

Dia TTS Server/dia-tts-server contains spaces, which can break tooling (CI scripts, Docker COPY, Makefiles) unless every reference is properly quoted. Consider switching to a hyphenated path, or—at minimum—verify all scripts handle it correctly.

-[submodule "Dia TTS Server/dia-tts-server"]
-	path = Dia TTS Server/dia-tts-server
+[# example – pick a consistent, no-space alias]
+[submodule "Dia-TTS-Server"]
+	path = Dia-TTS-Server

Would you confirm whether any existing scripts already assume a no-space path? If so, renaming now will prevent silent breakage later.


🏁 Script executed:

#!/bin/bash
# Search for any references to the submodule path with and without spaces
rg -n "Dia TTS Server"
rg -n "dia-tts-server"
rg -n "Dia-TTS-Server"

Length of output: 1003


Rename submodule directory to a hyphenated path (no spaces)

We found several unquoted references that will break if the on-disk path contains spaces:

• Dockerfile (Dia TTS Server/Dockerfile):
COPY dia-tts-server ./dia-tts-server
• docker-compose.yml (Dia TTS Server/docker-compose.yml):
volumes:
- ./dia-tts-server/model_cache:/sp/inputs/input-0001
• server-config.ts (Dia TTS Server/src/server-config.ts):
diaServerPath: path.join(__dirname, '../dia-tts-server')

Please update your .gitmodules entry and corresponding directory name:

-[submodule "Dia TTS Server/dia-tts-server"]
-	path = Dia TTS Server/dia-tts-server
+[submodule "Dia-TTS-Server"]
+	path = Dia-TTS-Server
 	url = https://github.com/devnen/Dia-TTS-Server.git

Then rename the folder on disk (and in any CI/Makefiles) to Dia-TTS-Server or flatten to dia-tts-server, and adjust all relative paths accordingly.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
[submodule "Dia TTS Server/dia-tts-server"]
path = Dia TTS Server/dia-tts-server
url = https://github.com/devnen/Dia-TTS-Server.git
[submodule "open_webui/open-webui"]
path = open_webui/open-webui
url = https://github.com/open-webui/open-webui.git
[submodule "Dia-TTS-Server"]
path = Dia-TTS-Server
url = https://github.com/devnen/Dia-TTS-Server.git
[submodule "open_webui/open-webui"]
path = open_webui/open-webui
url = https://github.com/open-webui/open-webui.git
🤖 Prompt for AI Agents
In the .gitmodules file around lines 9 to 14, the submodule directory "Dia TTS
Server/dia-tts-server" contains spaces which cause issues in unquoted path
references. Rename the submodule directory path to use hyphens instead of
spaces, such as "Dia-TTS-Server/dia-tts-server" or
"dia-tts-server/dia-tts-server". Update the .gitmodules file accordingly and
rename the actual folder on disk to match. Also, adjust all related references
in Dockerfile, docker-compose.yml, server-config.ts, CI scripts, and Makefiles
to use the new hyphenated path.

@@ -0,0 +1 @@
Subproject commit 2470da833679f61619f2275862185259fe7f5168
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Verification agent

🧩 Analysis chain

Pinning to an un-tagged SHA complicates provenance & future upgrades

The submodule is locked to a bare commit hash. Unless you have strong reasons, prefer referencing a signed tag or release to improve traceability and make git submodule update --remote upgrades easier. At minimum, document the upstream repo/commit in CHANGELOG and ensure CI fetches submodules.


🏁 Script executed:

#!/bin/bash
# Verify the exact commit exists upstream and that CI can fetch it quickly.
git submodule update --init --depth 1 open_webui/open-webui

Length of output: 402


🏁 Script executed:

#!/bin/bash
# Check if the pinned commit corresponds to any tag in upstream repo
git ls-remote --tags https://github.com/open-webui/open-webui.git | grep 2470da833679f61619f2275862185259fe7f5168 || echo "no matching tag"

Length of output: 156


Use a tagged release for the open-webui submodule

The commit 2470da833679f61619f2275862185259fe7f5168 isn’t referenced by any upstream tag, so pinning to this SHA makes provenance and future updates harder. Please either:

  • Update the submodule to point at the latest signed tag or release in open-webui/open-webui.git
  • If no suitable tag exists, create one upstream and retarget this submodule to it
  • At minimum, document the upstream repo URL and exact commit in your CHANGELOG
  • Ensure your CI config initializes and updates submodules (e.g. git submodule update --init --recursive)
🤖 Prompt for AI Agents
In open_webui/open-webui at line 1, the submodule is pinned to a specific commit
SHA without referencing a tagged release, which complicates provenance and
updates. Fix this by updating the submodule to point to the latest signed tag or
release in the upstream repository. If no suitable tag exists, create one
upstream and retarget the submodule to that tag. Additionally, document the
upstream repository URL and exact commit in the CHANGELOG, and verify that the
CI configuration properly initializes and updates submodules using commands like
'git submodule update --init --recursive'.

Comment on lines +1 to +8
export interface IServerConfig {
privateKeyFilePath: string;
certificateFilePath: string;
port: number;
tlsKey: string;
tlsCert: string;
openWebUIPath: string;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Unify duplicated server-config interfaces and mark immutables as readonly

The exact same IServerConfig shape appears in both the Open WebUI and Dia-TTS projects with only a single path-property difference.
Duplicating it risks the two copies drifting out of sync. Consider moving this interface to a small shared @sp/server-config package (or a common/ folder) and extending it where the path diverges:

export interface IBaseServerConfig {
  readonly privateKeyFilePath: string;
  readonly certificateFilePath: string;
  readonly port: number;
  readonly tlsKey: string;
  readonly tlsCert: string;
}

export interface IOpenWebUIServerConfig extends IBaseServerConfig {
  readonly openWebUIPath: string;
}

Marking the fields readonly documents that the object is effectively immutable after construction and enables a few extra compiler checks.

🤖 Prompt for AI Agents
In open_webui/src/types.ts lines 1 to 8, the IServerConfig interface duplicates
a similar interface in another project and lacks readonly modifiers. To fix
this, extract the common properties into a new IBaseServerConfig interface with
all fields marked readonly, then extend it in IOpenWebUIServerConfig to add the
openWebUIPath property also marked readonly. Consider moving IBaseServerConfig
to a shared package or common folder to avoid duplication and keep interfaces in
sync.

Comment on lines +1 to +8
export interface IServerConfig {
privateKeyFilePath: string;
certificateFilePath: string;
port: number;
tlsKey: string;
tlsCert: string;
diaServerPath: string;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

DRY violation – extract common IServerConfig instead of copy-pasting

This interface is byte-for-byte identical to the one in open_webui/src/types.ts, bar the path field. Duplicate definitions will inevitably diverge, leading to subtle runtime bugs when a new property is added to one service but not the other.

Refactor to import a shared base interface (see suggestion in the previous comment) and extend it with the project-specific diaServerPath.

🤖 Prompt for AI Agents
In Dia TTS Server/src/types.ts lines 1 to 8, the IServerConfig interface
duplicates the one in open_webui/src/types.ts except for the diaServerPath
field. To fix this, create a shared base interface in a common module and import
it here. Then extend that base interface with the diaServerPath property instead
of redefining all fields, ensuring consistency and avoiding duplication.

Comment on lines +6 to +8
"scripts": {
"build": "tsc -p tsconfig.build.json"
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Add a production-ready start script

Only a build script is declared. Without a start script, npm start or common Docker CMDs will fail at runtime.

   "scripts": {
     "build": "tsc -p tsconfig.build.json",
+    "start": "node dist/index.js"
   },
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"scripts": {
"build": "tsc -p tsconfig.build.json"
},
"scripts": {
"build": "tsc -p tsconfig.build.json",
"start": "node dist/index.js"
},
🤖 Prompt for AI Agents
In Dia TTS Server/package.json around lines 6 to 8, add a production-ready
"start" script to the "scripts" section. This script should run the compiled
output of the TypeScript build, typically using "node" to execute the main
JavaScript file generated by the build process. This ensures that running "npm
start" or Docker CMD commands will correctly start the application in
production.

Comment on lines +6 to +8
"scripts": {
"build": "tsc -p tsconfig.build.json"
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Add a start script for runtime execution

Same reasoning as in Dia-TTS package.

   "scripts": {
     "build": "tsc -p tsconfig.build.json",
+    "start": "node dist/index.js"
   },
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"scripts": {
"build": "tsc -p tsconfig.build.json"
},
"scripts": {
"build": "tsc -p tsconfig.build.json",
"start": "node dist/index.js"
},
🤖 Prompt for AI Agents
In open_webui/package.json around lines 6 to 8, the scripts section lacks a
"start" script for runtime execution. Add a "start" script that runs the built
application, typically using a command like "node dist/index.js" or the
appropriate entry point file, to enable easy startup of the app after building.

Comment on lines +54 to +55
# Install Ollama
RUN curl -fsSL https://ollama.com/install.sh | sh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Security risk with Ollama installation.

Piping curl output to shell presents a security vulnerability. Consider alternative installation methods.

For better security, consider using a more secure installation approach:

- # Install Ollama
- RUN curl -fsSL https://ollama.com/install.sh | sh
+ # Install Ollama with verification
+ RUN curl -fsSL https://ollama.com/install.sh -o /tmp/install-ollama.sh \
+     && chmod +x /tmp/install-ollama.sh \
+     && /tmp/install-ollama.sh \
+     && rm /tmp/install-ollama.sh
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
# Install Ollama
RUN curl -fsSL https://ollama.com/install.sh | sh
# Install Ollama with verification
RUN curl -fsSL https://ollama.com/install.sh -o /tmp/install-ollama.sh \
&& chmod +x /tmp/install-ollama.sh \
&& /tmp/install-ollama.sh \
&& rm /tmp/install-ollama.sh
🤖 Prompt for AI Agents
In open_webui/Dockerfile at lines 54 to 55, the current installation of Ollama
uses curl piped directly to sh, which is a security risk. To fix this, download
the install script first, verify its integrity (e.g., checksum or signature),
then execute it separately. Alternatively, use a trusted package manager or
official installation method that does not involve piping unverified scripts
directly to the shell.

clientServerPort: 9000,
serverFilePath: path.join(__dirname, './server.js'),
configurationPath: process.env.CONFIGURATION_PATH || '/sp/configurations/configuration.json',
localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Improve error handling for numeric parsing.

Number.parseInt() can return NaN if the environment variable contains invalid numeric data, which could cause runtime issues. Consider adding validation or using a more robust parsing approach.

- localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min
+ localServerStartTimeoutMs: (() => {
+   const value = Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000');
+   return Number.isNaN(value) ? 900000 : value;
+ })(),
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min
localServerStartTimeoutMs: (() => {
const value = Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000');
return Number.isNaN(value) ? 900000 : value;
})(),
🤖 Prompt for AI Agents
In open_webui/src/config.ts at line 23, the use of Number.parseInt on the
environment variable may result in NaN if the value is invalid. To fix this, add
validation after parsing to check if the result is NaN, and if so, fallback to a
default value or throw a clear error. This ensures the configuration always has
a valid numeric timeout value.

Comment on lines +1 to +24
import dotenv from 'dotenv';
import path from 'path';
import packageJson from '../package.json';
import { getEnvValueOrFail } from './env-utils';

dotenv.config();

export const config = {
appName: packageJson.name,
appVersion: packageJson.version,
blockchainUrl: getEnvValueOrFail('BLOCKCHAIN_URL'),
blockchainContractAddress: getEnvValueOrFail('BLOCKCHAIN_CONTRACT_ADDRESS'),
logLevel: (process.env.LOG_LEVEL as string) || 'trace',
inputDataFolder: (process.env.INPUT_DATA_FOLDER as string) || '/sp/inputs',
secretsDataFolder: (process.env.SECRETS_DATA_FOLDER as string) || '/sp/secrets',
certFileName: (process.env.CERT_FILE_NAME as string) || 'certificate.crt',
certPrivateKeyFileName: (process.env.CERT_PRIVATE_KEY_FILE_NAME as string) || 'private.pem',
configFileName: 'tunnel-client-config.json',
configSearchFolderDepth: 1 as number,
clientServerPort: 9000,
serverFilePath: path.join(__dirname, './server.js'),
configurationPath: process.env.CONFIGURATION_PATH || '/sp/configurations/configuration.json',
localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Significant code duplication detected.

This configuration file is nearly identical to open_webui/src/config.ts, which violates the DRY principle and increases maintenance overhead. Consider extracting the common configuration logic into a shared module or base configuration that both submodules can extend.

Consider creating a shared configuration module:

// shared/src/base-config.ts
export const createBaseConfig = (packageJson: any) => ({
  appName: packageJson.name,
  appVersion: packageJson.version,
  blockchainUrl: getEnvValueOrFail('BLOCKCHAIN_URL'),
  blockchainContractAddress: getEnvValueOrFail('BLOCKCHAIN_CONTRACT_ADDRESS'),
  // ... other common config
});

Then each submodule can extend this base configuration with specific overrides.

🤖 Prompt for AI Agents
In Dia TTS Server/src/config.ts lines 1 to 24, the configuration code duplicates
logic found in open_webui/src/config.ts, violating DRY principles. To fix this,
extract the shared configuration properties into a new shared module, for
example, shared/src/base-config.ts, which exports a function returning the
common config. Then, import and extend this base config in both Dia TTS Server
and open_webui config files, adding only module-specific overrides locally to
reduce duplication and ease maintenance.

Comment on lines +39 to +40
const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options);
await tunnelClient.start();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Missing resource cleanup for tunnel client.

The tunnel client is started but there's no explicit cleanup mechanism. Consider adding a shutdown handler to properly close the tunnel client on process termination.

  const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options);
+ 
+ // Add cleanup handler
+ process.on('SIGTERM', async () => {
+   logger.info('Received SIGTERM, shutting down tunnel client');
+   await tunnelClient.stop();
+   process.exit(0);
+ });
+ 
  await tunnelClient.start();
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options);
await tunnelClient.start();
const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options);
// Add cleanup handler
process.on('SIGTERM', async () => {
logger.info('Received SIGTERM, shutting down tunnel client');
await tunnelClient.stop();
process.exit(0);
});
await tunnelClient.start();
🤖 Prompt for AI Agents
In Dia TTS Server/src/index.ts around lines 39 to 40, the TunnelClient is
started but lacks a cleanup mechanism. Add a shutdown handler for process
termination signals (e.g., SIGINT, SIGTERM) that calls a method on tunnelClient
to properly close or stop it, ensuring resources are released gracefully when
the application exits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants