You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Increase timeout for staging fcrepo for cleaner startup
* Fix nginx to serve /system static assets directly instead of proxying to Puma
The Hyrax chart's nginx sidecar exists to keep Puma from serving
static files out of its small thread pool, but staging had no nginx
pod at all (nginx.enabled: false), and production's had no
extraVolumeMounts, so /system/* branding uploads passed straight
through to Puma either way. Enables nginx and mounts the existing
uploads PVC's public-system subPath, matching production's config
plus the actual fix.
* Bump staging hyrax web pod CPU limit/request, leave memory unchanged
Per calculate_limits_and_requests' r2-friends right-sizing report
(2026-07-28): actual p95/p99 CPU usage (597-748m) already close to the
old 1000m limit, and pals-stress-tests' before/after runs independently
confirmed real CPU throttling (~29-38% of periods) at that limit, both
before and after the nginx static-asset fix. Memory left alone -- p99
usage was ~869-895Mi against the existing 4Gi, no need there, and this
cluster's nodes are memory- not CPU-constrained, so growing memory here
would only make node bin-packing worse for no benefit.
Deliberately not touching RAILS_MAX_THREADS or Puma workers in this
change -- keeping this an isolated, single-variable test. HPA/autoscaling
is a separate, later effort with its own stress-test validation.
* Bake compiled assets/pdf.js/uv into a custom nginx image, matching HykuUp
Real traffic showed /assets/* (fonts/css/js, far higher volume than
the one tenant logo the /system fix covers) was still 100% proxied to
Puma -- 18s+ responses seen live -- because public/assets is baked
into the *web* image at build time, not on any EFS volume the stock
bitnami-nginx image could see. Fixed the same way HykuUp already does
it: a dedicated hyku-nginx Dockerfile stage copies these three paths
from the exact same commit as the web image, and CI now builds an
"nginx" component alongside web/worker/solr.
* Fix nginx websocket proxying for ActionCable realtime notifications
nginx's @rails proxy location stripped the Upgrade/Connection headers
before forwarding to Puma, so every websocket handshake for Hyrax's
realtime-notifications feature (/notifications/endpoint, mounted via
ActionCable, enabled by default) fell back to a plain HTTP request
that Rails' router 404s. Confirmed live: a raw handshake attempt
through staging's nginx returned a 404 exactly as described. Since the
client's ActionCable JS retries indefinitely with backoff, every open
tab from a logged-in user repeatedly re-hit this failing endpoint,
consuming Puma threads.
Added the standard map $http_upgrade $connection_upgrade pattern plus
proxy_http_version 1.1 and the Upgrade/Connection proxy headers on the
@rails location, in both friends (staging) and production nginx
serverBlocks -- only activates when a client actually sends an
Upgrade header, so it's a no-op for regular requests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* Reduce wordiness
* Include uv and pdf.js in static files served by nginx
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Fix production image to be the built one
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
0 commit comments