feat: install script to check for hard stops by aldy505 · Pull Request #4489 · getsentry/self-hosted

aldy505 · 2026-08-25T14:30:36Z

The idea came from Discord, and Alex (stayalive) lay out a very good approach on this: https://discord.com/channels/621778831602221064/796028405833007104/1541789134006259814

aldy505 · 2026-08-25T14:40:05Z

@aminvakil apparently, exit 0 terminates the install script. do you have any other suggestion for this? I want to avoid hadouken pattern.

EDIT; nevermind I just read this #4489 (comment), sorry about that

BYK · 2026-08-25T14:58:04Z

Just dropping this here: #3878 (review)

Overall, I think this is pretty good but we need a shared place and format to have the hard-stops so docs and the repo does not diverge. I'd propose JSON in a well-known location like the docs repo or this repo, and reading it with jq in the install script

aldy505 · 2026-08-26T00:59:38Z

Just dropping this here: #3878 (review)

Overall, I think this is pretty good but we need a shared place and format to have the hard-stops so docs and the repo does not diverge. I'd propose JSON in a well-known location like the docs repo or this repo, and reading it with jq in the install script

@BYK Yeah I remember about your comment. I don't know where the "shared place" should be. I don't want to have it on sentry, because I don't want to pull any image first, just for doing this. At the end of the day, I would think having these two separate would be good.

And yes, there will always be a maintenance burden for this one.

BYK · 2026-08-26T10:01:23Z

I don't want to have it on sentry, because I don't want to pull any image first, just for doing this

Not sure we are on the same page. My proposal is having this information in a separate, dedicated JSON file in this repo and then the docs repo fetching it at build time.

aldy505 · 2026-08-26T12:48:34Z

I don't want to have it on sentry, because I don't want to pull any image first, just for doing this

Not sure we are on the same page. My proposal is having this information in a separate, dedicated JSON file in this repo and then the docs repo fetching it at build time.

Aaaaaahhhhhh, that makes sense. I dunno how to do it on the docs repo, but making a JSON file here would be doable.

cursor

Stale Bugbot comment from a previous run.

The idea came from Discord, and Alex (stayalive) lay out a very good approach on this: https://discord.com/channels/621778831602221064/796028405833007104/1541789134006259814

cursor

Stale Bugbot comment from a previous run.

mhkarimi1383 · 2026-09-24T04:36:04Z

I think it's better to be on the Sentry's main source code in database migration part, not in install scripts, but it's better than nothing :)

aldy505 · 2026-09-24T06:06:54Z

I think it's better to be on the Sentry's main source code in database migration part, not in install scripts, but it's better than nothing :)

Sentry's main source code does not have the concept of "hard stop", as they're always deploying code from the "master" branch every hour.

mhkarimi1383 · 2026-09-24T06:32:43Z

But hard stop should be handled in other installation methods (like k8s)

aminvakil · 2026-09-24T10:22:24Z

But hard stop should be handled in other installation methods (like k8s)

There is no other installation methods supported, k8s support is outside of scope of getsentry.

Also you should really read release notes before upgrading 😉

aminvakil · 2026-09-24T10:33:02Z

+    # version is below any of them.
+    local _wrote_version=0
+    for hard_stop in "${hard_stops[@]}"; do
+      compare_result=$(compare_calver "$current_version" "$hard_stop")


I'd suggest using existing vergte function, also cursor and sentry bots about returning exit statuses are correct.

I don't think that is an equivalent function, as I need a detailed response rather than just a boolean (coming from the response of vergte)

aminvakil · 2026-09-24T10:34:37Z

+    local _wrote_version=0
+    for hard_stop in "${hard_stops[@]}"; do
+      compare_result=$(compare_calver "$current_version" "$hard_stop")
+      if [[ "$compare_result" == 0 ]]; then


I'm not sure if I understood this correctly, but let's say we are going from 26.5.0 to 26.8.0 and 26.7.0 is a hard-stop.

Doesn't this break outside of loop as soon as it sees 26.6.0 which is fine and not a hard-stop? never reaching 26.7.0?

aminvakil

Would you please address bots comments and mention me again afterwards?

jamgregory · 2026-09-24T10:44:09Z

Also you should really read release notes before upgrading 😉

I'll just point out that I had read the release notes during our more recent upgrade and had still missed that 26.7.0 was a hard stop. It would still be preferable for the script to alert you to this, just in case you accidentally miss it.

github-actions · 2026-09-26T01:37:16Z

Coverage Results 📊

✅ 22 passed | Total: 22 | Pass Rate: 100% | Execution Time: 11m 3s

📊 Comparison with Base Branch

Metric	Change
Total Tests	—
Passed Tests	—
Failed Tests	—
Skipped Tests	—

✨ Test counts unchanged from base.

All tests are passing successfully.

✅ Patch coverage is 100.00% (no changed executable lines found; target 50%).
Project statement coverage is 95.54% (unchanged from base (9aa721e) to head (2f43916)).

Coverage diff

@@            Coverage Diff             @@
##        master     #4489       +/-##
==========================================
  Coverage    95.54%    95.54%        —%
==========================================
  Files            5         5         —
  Tracked lines       336       336         —
  Branches         0         0         —
==========================================
  Hits           321       321         —
  Misses          15        15         —
  Partials         0         0         —

Generated by Coverage Action

BYK · 2026-09-24T10:12:20Z

+# Usage: compare_calver "1.2.3" "1.2.4"
+# Returns: -1 if first < second, 0 if equal, 1 if first > second
+#
+# This bit is written by Claude Haiku 4.5.


Haiku 4.5? What is this, the stone age? Use Luna at least 🤣

BYK · 2026-10-01T10:39:25Z

@@ -0,0 +1,198 @@
+# The idea of this file is to prevent users from skipping a hard stop.
+# This is done by creating a file in /var/run/sentry-hard-stop (or anything set
+# in HARD_STOP_FILE) and checking for its existence before. If the file exists,


I'm not sure if I like the "hard stop file" approach. Why can we not infer the previous version from the sentry image/instance itself? This is additional state we need to keep track of now.

How? We don't have sentry --version' kind of thing. Also this is being run after the user changed their .env` values.

We have these labels baked into the image which we can extend to versions or use to derive versions: https://github.com/getsentry/sentry/blob/c4bca2967197bc758abb1bc141c42f75902814d7/self-hosted/Dockerfile#L143-L145

I don't think we can fetch that. This works: docker inspect --format='{{index .Config.Labels "org.opencontainers.image.version"}}' ghcr.io/getsentry/sentry:26.9.0, but it outputs 91e940e6fe4df840c91d865b9d29df9a1b044faf rather than 26.9.0.

Also, we will never know the actual image being used, we need to use docker compose for that.

Actuallyyy, we can do this:

$ docker compose images --format json | jq 'first(.[] | select(.Repository == "ghcr.io/getsentry/snuba")) | .Tag' "26.9.0"

Can't do that with getsentry/sentry because of this:

{ "ID": "sha256:3e697ae50aec8548451fa0c4e75e906c69ce8fe3caf94c675bf924b3b00bb4db", "ContainerName": "sentry-self-hosted-taskscheduler-1", "Repository": "sentry-self-hosted-local", "Tag": "latest", "Platform": "linux/amd64", "Size": 1406387641, "Created": "2026-09-16T21:19:42.544492665+07:00", "LastTagTime": "2026-09-17T07:57:24.173640312+07:00" }

https://chatgpt.com/share/6abf746e-97d4-83eb-ae12-589d9feee97d

BYK · 2026-10-01T10:40:09Z

+
+# Helper function to parse version components
+# BASH_REMATCH requires Bash 3.0+
+_parse_version_components() {


Don't we already have these helpers somewhere for Docker version checks etc? We shouldn't be repeating this logic.

I didnt know. Probably would take another look at vergte, that Amin pointed out a few days ago.

Yeah, we should just consolidate the logic.

cursor

Stale Bugbot comment from a previous run.

…hard-stop

cursor

Cursor Bugbot has reviewed your changes and found 3 potential issues.

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

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

cursor · 2026-10-04T11:03:12Z

+fi
+
+if [[ -z "$new_version" ]]; then
+  new_version=$(grep -E '^SENTRY_IMAGE=' .env | sed 's/^.*=//' | cut -d: -f2 || true)


Image tag parsed from wrong field

High Severity

cut -d: -f2 splits on the colon in ghcr.io, so new_version becomes the image path rather than the tag. That value then fails the CalVer length check, and the hard-stop logic never runs for the default SENTRY_IMAGE.

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

cursor · 2026-10-04T11:03:12Z

+    if [[ "$current_version" == "$new_version" ]]; then
+      break
+    elif vergte "$hard_stop" "$current_version"; then
+      if vergte "$new_version" "$hard_stop"; then


Inclusive comparison flags valid upgrades

High Severity

vergte treats equality as a skipped hard stop, so upgrading to or away from a hard-stop version still triggers the warning. The prompt defaults to no and therefore cancels a valid upgrade.

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

cursor · 2026-10-04T11:03:12Z

+  echo "--------------------------------------------------------------------------------"
+else
+  # We use snuba image because we don't rebuild the image, and it preserves
+  current_version=$($dc images --format json | $jq -r 'first(.[] | select(.Repository == "ghcr.io/getsentry/snuba")) | .Tag')


Missing snuba image aborts install

High Severity

$dc images lists only created containers, and jq first exits non-zero when no ghcr.io/getsentry/snuba image is present. Under set -e that aborts first-time installs and upgrades after containers were removed.

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

sentry · 2026-10-04T11:06:55Z

+    if [[ "$current_version" == "$new_version" ]]; then
+      break
+    elif vergte "$hard_stop" "$current_version"; then
+      if vergte "$new_version" "$hard_stop"; then


Bug: The script incorrectly warns users they are skipping a hard-stop version when they are upgrading exactly to it, due to a >= check instead of >.
_{Severity: MEDIUM}

Suggested Fix

Change the version comparison at line 107 from vergte (greater than or equal to) to a strict greater-than check. This will ensure the warning only triggers when the new_version is actually newer than the hard_stop version, not equal to 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: install/check-hard-stop.sh#L107 Potential issue: The script uses `vergte` (version greater than or equal to) at line 107 to check if the `new_version` skips a `hard_stop` version. This comparison incorrectly returns true when the `new_version` is exactly equal to the `hard_stop` version. As a result, a user correctly upgrading *to* a required hard-stop version will receive a false and confusing warning message stating they are skipping the version they are trying to install. This will happen for every valid upgrade to any of the listed hard-stop versions.

sentry · 2026-10-04T11:06:55Z

+  echo "Good luck."
+  echo
+  echo "--------------------------------------------------------------------------------"
+elif [[ "${#new_version}" -gt 7 ]]; then


Bug: The CalVer length check (${#new_version} -gt 7) is too strict, causing valid versions to be flagged as invalid and silently skipping the hard-stop check.
_{Severity: HIGH}

Suggested Fix

Relax the version string length check at line 70 to accommodate valid CalVer formats that can be longer than 7 characters, such as those with two-digit months or patch numbers (e.g., YY.MM.DD).

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: install/check-hard-stop.sh#L70 Potential issue: A length check at line 70 (`${#new_version} -gt 7`) intended to validate CalVer versions is too restrictive. Valid Sentry CalVer strings can exceed 7 characters (e.g., `24.12.10` is 8 characters). When a user tries to upgrade to a valid version with a string longer than 7 characters, the script incorrectly identifies it as an invalid format. This causes the script to silently skip the entire hard-stop validation logic, potentially allowing a user to upgrade past a required hard-stop without any warning.

github-project-automation Bot added this to Self-hosted Sentry Aug 25, 2026

sentry Bot reviewed Aug 25, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

Comment thread install/check-hard-stop.sh Outdated

cursor Bot reviewed Aug 25, 2026

View reviewed changes

sentry Bot reviewed Aug 25, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

cursor Bot reviewed Aug 25, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

cursor Bot reviewed Aug 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

Comment thread install/check-hard-stop.sh Outdated

sentry Bot reviewed Aug 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

Comment thread install/check-hard-stop.sh Outdated

Comment thread install/check-hard-stop.sh Outdated

sentry Bot reviewed Aug 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

sentry Bot reviewed Aug 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

cursor Bot reviewed Aug 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

aldy505 added this pull request to stack #4507 September 13, 2026 15:09

aldy505 requested review from BYK and aminvakil September 13, 2026 15:25

aldy505 added 6 commits September 13, 2026 22:25

feat: install script to check for hard stops

132576e

The idea came from Discord, and Alex (stayalive) lay out a very good approach on this: https://discord.com/channels/621778831602221064/796028405833007104/1541789134006259814

fix: wrap exit code on a subshell

18d204f

fix: never have exit 0

3af65dd

fix: assign empty string to declaration

9377110

fix: address AI review comments

66deb84

feat: read hard-stops from json file

2472e2c

aldy505 force-pushed the aldy505/feat/check-hard-stop branch from 9b35c7d to 2472e2c Compare September 13, 2026 15:26

sentry Bot reviewed Sep 13, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

cursor Bot reviewed Sep 13, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

aldy505 mentioned this pull request Sep 24, 2026

Migration Hard Stops inforcement #4511

Open

aldy505 linked an issue Sep 24, 2026 that may be closed by this pull request

Migration Hard Stops inforcement #4511

Open

aminvakil reviewed Sep 24, 2026

View reviewed changes

aminvakil suggested changes Sep 24, 2026

View reviewed changes

aldy505 added 2 commits September 26, 2026 08:23

fix: code review comments

6478101

fix: shfmt

4fe5ccd

sentry Bot reviewed Sep 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh Outdated

fix: another attempt of code review comments

68967b9

sentry Bot reviewed Sep 26, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh

Comment thread install/check-hard-stop.sh Outdated

BYK reviewed Oct 1, 2026

View reviewed changes

ref: simplify check hard stop

2f43916

sentry Bot reviewed Oct 4, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh

cursor Bot reviewed Oct 4, 2026

View reviewed changes

Comment thread install/check-hard-stop.sh

Comment thread install/check-hard-stop.sh Outdated

aldy505 requested review from BYK and aminvakil October 4, 2026 09:36

aldy505 added 3 commits October 4, 2026 17:45

fix: bring back hard stop list file

412d4f8

Merge remote-tracking branch 'origin/master' into aldy505/feat/check-…

5fde6ba

…hard-stop

ref: handle check hard stop better

0a605e1

cursor Bot reviewed Oct 4, 2026

View reviewed changes

sentry Bot reviewed Oct 4, 2026

View reviewed changes

Uh oh!

Conversation

aldy505 commented Aug 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aldy505 commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BYK commented Aug 25, 2026

Uh oh!

aldy505 commented Aug 26, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BYK commented Aug 26, 2026

Uh oh!

aldy505 commented Aug 26, 2026

Uh oh!

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mhkarimi1383 commented Sep 24, 2026

Uh oh!

aldy505 commented Sep 24, 2026

Uh oh!

mhkarimi1383 commented Sep 24, 2026

Uh oh!

aminvakil commented Sep 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aminvakil left a comment

Choose a reason for hiding this comment

Uh oh!

jamgregory commented Sep 24, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage Results 📊

📊 Comparison with Base Branch

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aldy505 commented Aug 25, 2026 •

edited

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading

github-actions Bot commented Sep 26, 2026 •

edited

Loading

cursor Bot left a comment •

edited

Loading