test: Upgrade CI postgresql to v18

[beezz]

Run CI on Postgresql v18

[sentry]

Bug: The devservices/config.yml points the postgres dependency to a temporary feature branch, chore/upgrade-postgres-to-v18, which will likely be deleted after merging.
_{Severity: MEDIUM}

Suggested Fix

After the changes in the chore/upgrade-postgres-to-v18 branch are merged into the main branch of the sentry-shared-postgres repository, update devservices/config.yml to point the postgres dependency back to branch: main.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: devservices/config.yml#L41

Potential issue: The `devservices/config.yml` file is configured to use a temporary
feature branch, `chore/upgrade-postgres-to-v18`, for the `sentry-shared-postgres`
dependency. Feature branches are typically deleted after being merged. Once this branch
is deleted from the upstream repository, the `devservices up` command will fail for any
developer trying to set up their local environment, as it will be unable to clone the
specified branch. This will break the local development setup process.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: The CI workflow's PostgreSQL volume mount path is updated for v18, but it doesn't validate the actual image version, risking startup failure or silent data reset with older images.
_{Severity: CRITICAL}

Suggested Fix

Enforce the PostgreSQL version dependency. Either explicitly use a specific v18+ image tag instead of dynamically inspecting the running container, or add a step to verify the PostgreSQL version from the image before re-running the container with the new volume path. This ensures the volume mount path is compatible with the image being used.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/backend.yml#L253

Potential issue: The CI workflow in `.github/workflows/backend.yml` changes the
PostgreSQL volume mount path to be compatible with PostgreSQL v18. However, the actual
PostgreSQL image version is determined dynamically from a branch specified in
`devservices/config.yml` without any validation. If this process results in an older
(pre-v18) PostgreSQL image being used, the container will either fail to start or
silently initialize a new, empty database because the volume mount path will be
incorrect for that version. This could cause CI jobs to fail or to pass incorrectly with
tests running against an empty database.

Also affects:

• devservices/config.yml:41~41

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit e323490. Configure here.}

[cursor]

Temporary feature branch dependency pin

High Severity

postgres in devservices/config.yml is pinned to the temporary branch chore/upgrade-postgres-to-v18 instead of main. If this lands, local devservices and CI depend on that branch; once it is merged or deleted, postgres startup fails for everyone.

 

^{Reviewed by Cursor Bugbot for commit e323490. Configure here.}

[sentry]

Bug: The PostgreSQL volume is mounted at /var/lib/postgresql instead of the expected /var/lib/postgresql/data, causing the database to be re-initialized mid-workflow and losing all test setup data.
_{Severity: HIGH}

Suggested Fix

Revert the Docker volume mount path in the docker run command back to -v postgres-data:/var/lib/postgresql/data. This will ensure the restarted container finds the existing database data initialized by devservices and prevents data loss during the CI run.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/backend.yml#L252

Potential issue: The CI workflow first initializes a PostgreSQL database using
`devservices`, which stores data in the standard `/var/lib/postgresql/data` directory
within the `postgres-data` volume. However, a subsequent step in the workflow stops this
container and restarts it with the volume mounted at `/var/lib/postgresql` instead. When
the new container starts, PostgreSQL looks for its data at `/var/lib/postgresql/data`
relative to the new mount point, finds an empty directory, and re-initializes the
database from scratch. This erases all the initial database setup, including schema
migrations, causing subsequent tests that rely on the database to fail.

Also affects:

• devservices/config.yml:41~41

[sentry]

Bug: A potential mismatch exists between the PostgreSQL volume mount path in the initial container setup (/var/lib/postgresql/data) and the reconnect step (/var/lib/postgresql), which could cause data loss during CI runs.
_{Severity: HIGH}

Suggested Fix

Verify that the configuration in the sentry-shared-postgres repository on the chore/upgrade-postgres-to-v18 branch also mounts the PostgreSQL volume at /var/lib/postgresql. If it uses the old path, it must be updated to match the path in the backend.yml workflow to ensure consistency.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/backend.yml#L253

Potential issue: The CI workflow first starts a PostgreSQL container using a
configuration from the `sentry-shared-postgres` repository. A later step reconnects to
this database by starting a new container using the same volume. The pull request
updates the reconnect step's volume mount path to `/var/lib/postgresql` to support
PostgreSQL 18. However, if the initial container setup defined in the external
`sentry-shared-postgres` repository still uses the old mount path
(`/var/lib/postgresql/data`), the reconnected container will not find the existing data.
This would cause it to initialize a new, empty database, leading to failures in all
subsequent database-dependent tests.

Also affects:

• devservices/config.yml:41

[sentry]

Bug: The postgres service in devservices/config.yml points to a temporary feature branch, chore/upgrade-postgres-to-v18, which will likely be deleted, breaking local development and CI.
_{Severity: HIGH}

Suggested Fix

The postgres service configuration in devservices/config.yml should be updated to point to a stable branch, such as main, after the changes from the chore/upgrade-postgres-to-v18 branch are merged in the sentry-shared-postgres repository.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: devservices/config.yml#L41

Potential issue: The `devservices/config.yml` file configures the `postgres` service to
use the `chore/upgrade-postgres-to-v18` branch. Unlike other services which point to
stable branches like `main` or `master`, this branch is temporary. Once this feature
branch is merged and deleted from its repository, any attempt to run `devservices up`
will fail. This will block all local development and break multiple CI workflows that
rely on this configuration, as there is no fallback mechanism to a stable branch.

[sentry]

Bug: The Postgres container is recreated without the PGDATA environment variable, which can cause data inaccessibility or loss in CI due to path mismatches in PostgreSQL 18.
_{Severity: HIGH}

Suggested Fix

Explicitly pass the PGDATA environment variable to the docker run command in the "Reconnect postgres via Unix socket" step. This ensures the recreated container uses the same data directory as the original container. For example, add -e PGDATA=/var/lib/postgresql/18/docker or dynamically retrieve the value from the original container before stopping it.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/backend.yml#L250-L256

Potential issue: The CI workflow recreates the PostgreSQL container in the "Reconnect
postgres via Unix socket" step. However, the `docker run` command used for recreation
does not pass the `PGDATA` environment variable. The PostgreSQL 18 Docker image uses a
version-specific default for `PGDATA` (e.g., `/var/lib/postgresql/18/docker`). If the
original container used a specific `PGDATA` path, the recreated container will default
to a different one. This mismatch will cause the container to either fail to start or
initialize a new, empty database, leading to data loss within the CI run and causing
subsequent tests to fail.