prodeng-605: migrate uwsgi to granian#7566
Merged
Merged
Conversation
gi0baro
force-pushed
the
gi0baro/drop-uwsgi
branch
3 times, most recently
from
December 2, 2025 14:33
aa68515 to
f9079b5
Compare
gi0baro
force-pushed
the
gi0baro/drop-uwsgi
branch
from
January 12, 2026 13:40
a963e77 to
b260d35
Compare
gi0baro
marked this pull request as ready for review
January 12, 2026 13:41
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
phacops
reviewed
Jan 12, 2026
| interface=Interfaces.WSGI, | ||
| backlog=backlog, | ||
| workers=processes, | ||
| workers_lifetime=lifetime, |
Contributor
There was a problem hiding this comment.
What does lifetime do, especially when None since we don't specify a value when we start the API? Don't we want the process to be recycled regularly due to our
Member
Author
There was a problem hiding this comment.
When is None the workers have no max lifetime.
I'm not 100% sure we want a default value, also because we don't use the CLI command to run snuba on our side.
phacops
approved these changes
Jan 12, 2026
onewland
added a commit
that referenced
this pull request
May 7, 2026
Drop the `/tmp/snuba.down` drain mechanism, which has been a no-op since the granian migration. The mechanism worked by having a uwsgi worker consult `uwsgi.started_on` and compare it to the down file's mtime. When we migrated from uwsgi to granian in #7566, `pyuwsgi` was dropped from runtime deps and the Dockerfile, so `import uwsgi` has always failed and `check_down_file_exists()` has returned `False` ever since. I also checked that nothing references this drain mechanism anymore (since getsentry/ops#17972). Removed: - `snuba/utils/health_info.py`: the `try: import uwsgi` block, `shutdown_time`, `_IS_SHUTTING_DOWN`, `_set_shutdown`, `get_shutdown`, `check_down_file_exists`, and the `down_file_exists` field/tag in `/health` output and metrics. - `snuba/web/views.py`: the `check_shutdown` function (5%-sampled disk check that was always no-op) and both call sites in `dataset_query` and `storage_delete`. - Tests for the above. `/health_envoy` is **kept as a static 200 tombstone** so existing envoy callers don't start 404'ing. Today the endpoint already always returns 200 (because `check_down_file_exists()` always returns `False`), so this preserves runtime behavior. It can be removed in a follow-up once the envoy-side config no longer references the path. This is a prerequisite for the INC-2141 health-check change — that PR will be opened against this branch and removes the side-effect that surfaced the dead `import uwsgi` (mypy was newly resolving the import inside `health_info.py` after #7566 dropped it from the type-stub allowlist, blocking commits to that file). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SSIA