Skip to content

Added TLSN proxy service and make Telegram backend host configurable#757

Open
SergeyG-Solicy wants to merge 2 commits intotestnetfrom
feature/tlsn-proxy-configurable-backends
Open

Added TLSN proxy service and make Telegram backend host configurable#757
SergeyG-Solicy wants to merge 2 commits intotestnetfrom
feature/tlsn-proxy-configurable-backends

Conversation

@SergeyG-Solicy
Copy link
Copy Markdown
Contributor

@SergeyG-Solicy SergeyG-Solicy commented Apr 6, 2026

Summary by CodeRabbit

  • New Features

    • Added configurable Telegram backend host environment variable
    • Introduced TLSNotary proxy service for WebSocket-to-TCP communication
  • Chores

    • Updated Docker Compose to include a proxy service, dedicated network, and proxy-related configuration
    • Added TLSNotary environment configuration file with documented variables and usage notes

@SergeyG-Solicy SergeyG-Solicy requested a review from tcsenpai April 6, 2026 07:28
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 6, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 769679db-b216-4d48-8c54-431b2f8b5f4b

📥 Commits

Reviewing files that changed from the base of the PR and between 069bccd and 2d96b16.

📒 Files selected for processing (1)
  • tlsnotary/Dockerfile.proxy
✅ Files skipped from review due to trivial changes (1)
  • tlsnotary/Dockerfile.proxy

Walkthrough

Adds a TLSNotary WebSocket-to-TCP proxy and compose stack, introduces TLSNotary env examples, and makes Telegram backend host configurable plus small identity-dispatcher updates to recognize additional TLSNotary operation names.

Changes

Cohort / File(s) Summary
Environment examples
./.env.example, tlsnotary/.env.example
Added TLSN_TELEGRAM_BACKEND_HOST to root example and added a TLSNotary-specific .env.example with TLSNOTARY_PORT and PROXY_PORT and usage notes.
Identity routing & TLSN config
src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts
Loaded Telegram TLSNotary server host from process.env.TLSN_TELEGRAM_BACKEND_HOST with fallback; added tlsn_identity_assign and tlsn_identity_remove to TLSNotary operation cases; adjusted error message string formatting.
TLSNotary proxy & compose
tlsnotary/Dockerfile.proxy, tlsnotary/docker-compose.yml
Added two-stage Dockerfile building wstcp proxy and a reworked docker-compose with notary + proxy services on a tlsn bridge network, exposing configurable host PROXY_PORT → container 55688.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant Proxy as "wstcp Proxy\n(runs in container)"
  participant Notary as "Notary Service\n(container: notary:7047)"

  Client->>Proxy: WebSocket connect to PROXY_PORT
  Proxy->>Notary: TCP connect to notary:7047
  Client->>Proxy: Send request (TLSNotary protocol)
  Proxy->>Notary: Forward TCP payload
  Notary-->>Proxy: Response
  Proxy-->>Client: Relay over WebSocket
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I tunneled webs to TCP with cheer,
Env keys placed so hosts are clear.
Two services now hop and play,
Assign and remove find their way—
A tiny hop for notary gear.

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the two main changes: adding a TLSN proxy service and making the Telegram backend host configurable, both clearly reflected in the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/tlsn-proxy-configurable-backends

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@qodo-code-review
Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Add TLSN proxy service and configurable Telegram backend host

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add TLSN proxy service for WebSocket-to-TCP bridging
• Make Telegram backend host configurable via environment variable
• Support new identity operation aliases for TLSN identity management
• Improve TLSNotary Docker Compose setup with proxy service
Diagram
flowchart LR
  A["TLSN_TELEGRAM_BACKEND_HOST<br/>Environment Variable"] -->|"configures"| B["Telegram Backend<br/>Server Address"]
  C["wstcp Proxy<br/>Service"] -->|"forwards WebSocket"| D["TLSNotary Notary<br/>Server"]
  E["New Identity<br/>Operation Aliases"] -->|"tlsn_identity_assign<br/>tlsn_identity_remove"| F["TLSN Identity<br/>Routines"]
Loading

Grey Divider

File Changes

1. src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts ✨ Enhancement +15/-14

Configurable Telegram backend and identity operation aliases

• Made Telegram backend host configurable via TLSN_TELEGRAM_BACKEND_HOST environment variable
• Added support for new identity operation aliases tlsn_identity_assign and tlsn_identity_remove
• Fixed code formatting and indentation in error messages and endpoint configuration

src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts


2. .env.example ⚙️ Configuration changes +4/-0

Add Telegram backend host configuration variable

• Added TLSN_TELEGRAM_BACKEND_HOST environment variable with documentation
• Includes example value and explanation of required configuration

.env.example


3. tlsnotary/.env.example ⚙️ Configuration changes +12/-0

TLSNotary environment configuration template

• New file providing environment variable template for TLSNotary stack
• Documents TLSNOTARY_PORT and PROXY_PORT configuration options

tlsnotary/.env.example


View more (2)
4. tlsnotary/Dockerfile.proxy ✨ Enhancement +28/-0

WebSocket-to-TCP proxy Docker image

• New Dockerfile for building wstcp WebSocket-to-TCP proxy service
• Multi-stage build using Rust Alpine for compilation and Alpine for runtime
• Exposes port 55688 and accepts TCP target as command argument

tlsnotary/Dockerfile.proxy


5. tlsnotary/docker-compose.yml ✨ Enhancement +30/-18

Add proxy service and improve Docker Compose setup

• Added new proxy service using wstcp for WebSocket-to-TCP bridging
• Removed healthcheck from notary service
• Added shared tlsn network for service communication
• Updated documentation to describe both notary and proxy services
• Made ports configurable via environment variables

tlsnotary/docker-compose.yml


Grey Divider

Qodo Logo

@qodo-code-review
Copy link
Copy Markdown
Contributor

qodo-code-review bot commented Apr 6, 2026

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

Grey Divider


Action required

1. Proxy port env mismatch 🐞 Bug ≡ Correctness
Description
tlsnotary/docker-compose.yml exposes the proxy on PROXY_PORT, but the node’s tlsnotary.getInfo
endpoint advertises the proxy using TLSNOTARY_PROXY_PORT; if they diverge, SDK clients will receive
an incorrect proxyUrl and fail to connect. This is easy to misconfigure because the two variables
are named differently and live in different .env files.
Code

tlsnotary/docker-compose.yml[R27-33]

+    proxy:
+        container_name: tlsn-proxy-${PROXY_PORT:-55688}
+        build:
+            context: .
+            dockerfile: Dockerfile.proxy
+        ports:
+            - "${PROXY_PORT:-55688}:55688"
Evidence
The new TLSNotary stack maps the proxy container’s host port from PROXY_PORT, while the node
constructs the advertised proxyUrl from TLSNOTARY_PROXY_PORT. Unless operators keep these two
variables identical, the node will announce a port that doesn’t actually have a proxy listening.

tlsnotary/docker-compose.yml[27-37]
src/libs/network/manageNodeCall.ts[643-670]
tlsnotary/.env.example[9-12]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The TLSNotary proxy port is configured with `PROXY_PORT` in `tlsnotary/docker-compose.yml`, but the node advertises the proxy endpoint using `TLSNOTARY_PROXY_PORT`. If these values differ, clients will attempt to connect to the wrong port.

### Issue Context
- Docker compose controls what port is actually exposed on the host.
- `tlsnotary.getInfo` is used for SDK auto-configuration and must return the real reachable proxy port.

### Fix Focus Areas
- Make docker-compose use `TLSNOTARY_PROXY_PORT` (or make the node read `PROXY_PORT` too), so there is a single source of truth.
- Update the tlsnotary `.env.example` accordingly.

- tlsnotary/docker-compose.yml[27-37]
- tlsnotary/.env.example[6-12]
- src/libs/network/manageNodeCall.ts[643-670]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. TLSN operation naming inconsistent 🐞 Bug ≡ Correctness
Description
GCRIdentityRoutines.apply() routes identity edits using identityEdit.context + operation (e.g.,
tlsnadd/tlsnremove), but this PR adds tlsn_identity_assign/remove case labels, mixing two
different naming schemes. If upstream sends method-style names (as used elsewhere in transaction
verification), edits can still miss the intended handler and be rejected as unsupported.
Code

src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[R1202-1213]

            case "tlsnadd":
+            case "tlsn_identity_assign":
                result = await this.applyTLSNIdentityAdd(
                    identityEdit,
                    gcrMainRepository,
                    simulate,
                )
                break
-            
+
            case "tlsnremove":
+            case "tlsn_identity_remove":
                result = await this.applyTLSNIdentityRemove(
Evidence
The switch key is explicitly constructed from context + operation, and other code paths define
identity edits with operation: "add" | "remove", while transaction verification uses method
strings like tlsn_identity_assign/remove. Adding tlsn_identity_assign as a case label doesn’t
resolve the mismatch unless the edit format is normalized to match what the switch actually
computes.

src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1052-1083]
src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1202-1218]
src/libs/omniprotocol/protocol/handlers/gcr.ts[32-40]
src/libs/network/routines/transactions/handleIdentityRequest.ts[111-129]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`GCRIdentityRoutines.apply()` dispatches identity edits by `context + operation` (e.g. `tlsnadd`). The PR adds `tlsn_identity_assign/remove` case labels, but the codebase already uses method-style strings (`tlsn_identity_assign/remove`) in transaction verification, and add/remove-style in GCR edits.

### Issue Context
Without a single canonical mapping, some producers may emit method-style names while others emit add/remove-style edits, leading to missed switch matches and "Unsupported identity operation" failures.

### Fix Focus Areas
- Either remove the `tlsn_identity_*` case labels and keep the canonical `context='tlsn', operation='add|remove'` scheme, OR
- Add a normalization step before the switch that converts any method-style representation into the canonical `context + operation` key used by the switch.

- src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1052-1073]
- src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1202-1218]
- src/libs/network/routines/transactions/handleIdentityRequest.ts[111-129]
- src/libs/omniprotocol/protocol/handlers/gcr.ts[32-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Telegram TLSN host unused 🐞 Bug ⚙ Maintainability
Description
TLSN_TELEGRAM_BACKEND_HOST is wired into TLSN_EXPECTED_ENDPOINTS, but proof verification currently
never uses the configured server/pathPrefix fields, so changing this env var does not change which
proofs are accepted. This makes the new configuration misleading and suggests the intended
host-binding check is missing.
Code

src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[R1816-1819]

+            telegram: {
+                server: process.env.TLSN_TELEGRAM_BACKEND_HOST ?? "telegram-backend",
+                pathPrefix: "/api/telegram/user",
+            },
Evidence
GCRIdentityRoutines stores the host in TLSN_EXPECTED_ENDPOINTS, but in the TLSN identity flow it
only checks that an entry exists for the context. The TLSN verifier performs structure-only proof
checks and validates disclosed recv bytes / extracted user fields, without validating server name or
request path against TLSN_EXPECTED_ENDPOINTS.

src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1807-1820]
src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1907-1913]
src/libs/tlsnotary/verifier.ts[513-584]
src/libs/tlsnotary/verifier.ts[724-818]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`TLSN_TELEGRAM_BACKEND_HOST` is introduced to configure the expected Telegram backend host, but the verification code path never consumes `TLSN_EXPECTED_ENDPOINTS.{server,pathPrefix}`—only the presence of a context key is checked. This makes the config ineffective.

### Issue Context
- `TLSN_EXPECTED_ENDPOINTS` suggests an intent to bind proofs to expected endpoints.
- Current verifier logic validates proof structure + disclosed recv content but does not validate the endpoint.

### Fix Focus Areas
- Either implement endpoint validation (server + path prefix) in the TLSN verification flow, or remove the unused `server/pathPrefix` config to avoid misleading operators.

- src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1807-1820]
- src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts[1907-1913]
- src/libs/tlsnotary/verifier.ts[513-584]
- src/libs/tlsnotary/verifier.ts[724-818]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Unpinned wstcp install 🐞 Bug ☼ Reliability
Description
Dockerfile.proxy installs wstcp with cargo install wstcp without pinning a version or using
--locked, making proxy builds non-reproducible and vulnerable to upstream breakage. A future wstcp
release could change behavior or fail to build, breaking deployments unexpectedly.
Code

tlsnotary/Dockerfile.proxy[R10-15]

+FROM rust:alpine AS builder
+
+RUN apk add --no-cache musl-dev
+
+RUN cargo install wstcp
+
Evidence
The proxy image build pulls whatever the latest wstcp is at build time; without a version pin or
locked dependencies, the produced image can vary across builds and time.

tlsnotary/Dockerfile.proxy[10-15]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The proxy Dockerfile uses `cargo install wstcp` without pinning a version (and without `--locked`). This makes builds non-deterministic.

### Issue Context
Non-reproducible builds can break CI/CD or production rebuilds when upstream crates change.

### Fix Focus Areas
- Pin an explicit version (and ideally use `--locked`) when installing.
- Optionally switch to a prebuilt artifact or include a Cargo.lock workflow for deterministic builds.

- tlsnotary/Dockerfile.proxy[10-15]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Copy link
Copy Markdown
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: 1

🧹 Nitpick comments (4)
tlsnotary/.env.example (1)

9-12: Consider documenting the variable name difference.

The root .env.example uses TLSNOTARY_PROXY_PORT (line 76) while this file uses PROXY_PORT. The comment mentions this alignment requirement, but users may be confused by the different names. Consider adding a brief note explaining why the naming differs (e.g., this is for Docker Compose interpolation vs. node application config).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@tlsnotary/.env.example` around lines 9 - 12, The comment in the TLS notary
env uses PROXY_PORT but the root .env.example uses TLSNOTARY_PROXY_PORT which
can confuse users; update the comment near PROXY_PORT to explicitly state the
variable name difference (e.g., "Note: root .env uses TLSNOTARY_PROXY_PORT while
this file uses PROXY_PORT for Docker Compose interpolation / node app config")
and explain that they must match at runtime (TLSNOTARY_PROXY_PORT ↔ PROXY_PORT)
so users know to keep values in sync.
tlsnotary/docker-compose.yml (1)

27-42: Proxy service configuration looks good.

The service correctly depends on notary, uses Docker DNS (notary:7047) to forward traffic, and shares the tlsn network. The YAMLlint warning about redundant quotes on line 37 is a false positive—the colon in notary:7047 requires quoting for unambiguous parsing.

Consider adding a healthcheck for improved observability in production:

♻️ Optional healthcheck addition
     proxy:
         container_name: tlsn-proxy-${PROXY_PORT:-55688}
         build:
             context: .
             dockerfile: Dockerfile.proxy
         ports:
             - "${PROXY_PORT:-55688}:55688"
         command: ["notary:7047"]
         restart: unless-stopped
         depends_on:
             - notary
         networks:
             - tlsn
+        healthcheck:
+            test: ["CMD-SHELL", "nc -z localhost 55688 || exit 1"]
+            interval: 30s
+            timeout: 5s
+            retries: 3

Note: This requires adding netcat-openbsd to the Dockerfile.proxy runtime image.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@tlsnotary/docker-compose.yml` around lines 27 - 42, Add a container
healthcheck to the proxy service to improve observability: in the proxy service
block (service name "proxy" and its command "notary:7047") add a healthcheck
that probes the notary TCP port (e.g., using nc) and tune interval/retries; also
update Dockerfile.proxy to install netcat-openbsd (or another lightweight probe
tool) in the runtime image so the healthcheck command is available. Ensure the
healthcheck uses the internal DNS target "notary:7047" and set sensible
timeout/interval/retries for production.
src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts (1)

1810-1820: Document the non-Docker deployment requirement for TLSN_TELEGRAM_BACKEND_HOST.

The static property TLSN_EXPECTED_ENDPOINTS initializes with process.env.TLSN_TELEGRAM_BACKEND_HOST ?? "telegram-backend" at module load time. The environment variable is documented in .env.example but lacks clarification that "telegram-backend" is an internal service name that requires explicit configuration outside containerized deployments. Add a note to .env.example or deployment documentation specifying that TLSN_TELEGRAM_BACKEND_HOST must be explicitly set for non-Docker environments.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts` around lines
1810 - 1820, The TLSN_EXPECTED_ENDPOINTS static map uses
process.env.TLSN_TELEGRAM_BACKEND_HOST ?? "telegram-backend" at module load, so
the default "telegram-backend" is an internal Docker service name; update
documentation by adding a clear note to .env.example (or deployment docs) that
TLSN_TELEGRAM_BACKEND_HOST must be explicitly set to the reachable host/FQDN
when running outside Docker (e.g., on developer machines or production VMs),
include an example value and a short explanation referencing the
TLSN_EXPECTED_ENDPOINTS constant and the TLSN_TELEGRAM_BACKEND_HOST env var so
operators know to override the default for non-containerized deployments.
tlsnotary/Dockerfile.proxy (1)

14-14: Pin the wstcp version for reproducible builds.

cargo install wstcp installs the latest version, which can change between builds and lead to unexpected behavior when rebuilding the image. Pin to a specific version for reproducibility.

♻️ Proposed fix
-RUN cargo install wstcp
+RUN cargo install wstcp --version 0.2.1
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@tlsnotary/Dockerfile.proxy` at line 14, The Dockerfile's RUN line installs
wstcp without a version, causing non-reproducible builds; update the RUN command
that currently reads "cargo install wstcp" to pin a specific release (use cargo
install --version "x.y.z" with the chosen semver) and include --locked to ensure
Cargo.lock is respected, so replace the bare install in the Dockerfile.proxy
with a version-pinned, locked cargo install invocation for wstcp.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@tlsnotary/Dockerfile.proxy`:
- Around line 16-28: Add a non-root user and switch to it in the proxy image:
create a dedicated user/group (e.g., tlsproxy), chown the copied binary
(/usr/local/bin/wstcp) and any needed certs to that user, and add a USER
tlsproxy line before ENTRYPOINT/CMD so the container no longer runs as root;
ensure the user has a home and a non-login shell as needed and that file
permissions are adjusted so wstcp is executable by that user.

---

Nitpick comments:
In `@src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts`:
- Around line 1810-1820: The TLSN_EXPECTED_ENDPOINTS static map uses
process.env.TLSN_TELEGRAM_BACKEND_HOST ?? "telegram-backend" at module load, so
the default "telegram-backend" is an internal Docker service name; update
documentation by adding a clear note to .env.example (or deployment docs) that
TLSN_TELEGRAM_BACKEND_HOST must be explicitly set to the reachable host/FQDN
when running outside Docker (e.g., on developer machines or production VMs),
include an example value and a short explanation referencing the
TLSN_EXPECTED_ENDPOINTS constant and the TLSN_TELEGRAM_BACKEND_HOST env var so
operators know to override the default for non-containerized deployments.

In `@tlsnotary/.env.example`:
- Around line 9-12: The comment in the TLS notary env uses PROXY_PORT but the
root .env.example uses TLSNOTARY_PROXY_PORT which can confuse users; update the
comment near PROXY_PORT to explicitly state the variable name difference (e.g.,
"Note: root .env uses TLSNOTARY_PROXY_PORT while this file uses PROXY_PORT for
Docker Compose interpolation / node app config") and explain that they must
match at runtime (TLSNOTARY_PROXY_PORT ↔ PROXY_PORT) so users know to keep
values in sync.

In `@tlsnotary/docker-compose.yml`:
- Around line 27-42: Add a container healthcheck to the proxy service to improve
observability: in the proxy service block (service name "proxy" and its command
"notary:7047") add a healthcheck that probes the notary TCP port (e.g., using
nc) and tune interval/retries; also update Dockerfile.proxy to install
netcat-openbsd (or another lightweight probe tool) in the runtime image so the
healthcheck command is available. Ensure the healthcheck uses the internal DNS
target "notary:7047" and set sensible timeout/interval/retries for production.

In `@tlsnotary/Dockerfile.proxy`:
- Line 14: The Dockerfile's RUN line installs wstcp without a version, causing
non-reproducible builds; update the RUN command that currently reads "cargo
install wstcp" to pin a specific release (use cargo install --version "x.y.z"
with the chosen semver) and include --locked to ensure Cargo.lock is respected,
so replace the bare install in the Dockerfile.proxy with a version-pinned,
locked cargo install invocation for wstcp.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d4e5d0bd-5876-466c-ad91-866ce657030a

📥 Commits

Reviewing files that changed from the base of the PR and between 50ab546 and 069bccd.

📒 Files selected for processing (5)
  • .env.example
  • src/libs/blockchain/gcr/gcr_routines/GCRIdentityRoutines.ts
  • tlsnotary/.env.example
  • tlsnotary/Dockerfile.proxy
  • tlsnotary/docker-compose.yml

Comment on lines +27 to +33
proxy:
container_name: tlsn-proxy-${PROXY_PORT:-55688}
build:
context: .
dockerfile: Dockerfile.proxy
ports:
- "${PROXY_PORT:-55688}:55688"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

1. Proxy port env mismatch 🐞 Bug ≡ Correctness

tlsnotary/docker-compose.yml exposes the proxy on PROXY_PORT, but the node’s tlsnotary.getInfo
endpoint advertises the proxy using TLSNOTARY_PROXY_PORT; if they diverge, SDK clients will receive
an incorrect proxyUrl and fail to connect. This is easy to misconfigure because the two variables
are named differently and live in different .env files.
Agent Prompt
### Issue description
The TLSNotary proxy port is configured with `PROXY_PORT` in `tlsnotary/docker-compose.yml`, but the node advertises the proxy endpoint using `TLSNOTARY_PROXY_PORT`. If these values differ, clients will attempt to connect to the wrong port.

### Issue Context
- Docker compose controls what port is actually exposed on the host.
- `tlsnotary.getInfo` is used for SDK auto-configuration and must return the real reachable proxy port.

### Fix Focus Areas
- Make docker-compose use `TLSNOTARY_PROXY_PORT` (or make the node read `PROXY_PORT` too), so there is a single source of truth.
- Update the tlsnotary `.env.example` accordingly.

- tlsnotary/docker-compose.yml[27-37]
- tlsnotary/.env.example[6-12]
- src/libs/network/manageNodeCall.ts[643-670]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud bot commented Apr 6, 2026

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.

1 participant