1. Release Notes
  2. Release 1.62.0

Deployment & Settings Changes - v1.62.0

Release: v1.62.0 Date: 2026-04-09

Summary

Impact Level: MEDIUM

Action Required: NO (zero-touch upgrade; see “Expected Side Effects”)

Backward Compatible: YES

Quick Decision Matrix

Component/Area Change Type Risk Level Action Required Impact
Environment Variables No changes NONE NO —
Database Schema Migrations V99, V100 LOW NO Auto-applied by Flyway on startup
Authentication Spring Session removed MEDIUM NO All editor users signed out on upgrade
Kubernetes/Helm Postgres private LB unmanaged LOW NO Internal cluster only
Docker Images Standard rebuild NONE NO —
Runtime Dependencies spring-session-* removed LOW NO Backend bundle smaller
Build Dependencies Vite 7.3.1 → 7.3.2 LOW NO Dev-server CVE patches
Monitoring/Logging New SaaS Fleet dashboard, analytics schema LOW NO Internal cluster only

Deployment Decision

Overall Risk: LOW

Recommended Action: APPROVE

Downtime Required: NO — zero-downtime supported. Rolling restart of editor-service pods is enough.

Rollback Risk: MEDIUM — V99 drops tables (spring_session, spring_session_attributes). A downgrade to a pre-1.62.0 image would boot but the old Spring Session layer would silently recreate the tables empty and every logged-in user would stay signed out anyway. Treat the upgrade as one-way for session state.

Configuration Changes

Environment Variables

None. No new, modified, or deprecated environment variables in this release.

Helm Values

None that affect customer deployments.

On the internal cluster, the prod seatmap-postgresql-private Service is now managed imperatively via kubectl and not by Helm. This is internal infrastructure only — customer deployments are unaffected. Details are in the CLAUDE.md “Analytics DB access pattern” section and the internal runbook docs/VSWITCH_PRIVATE_ACCESS.md.

Database Changes

V99 — V99__drop_spring_session.sql

Drops the spring_session and spring_session_attributes tables.

DROP TABLE IF EXISTS spring_session_attributes;
DROP TABLE IF EXISTS spring_session;

Context: editor-service used to run two auth layers simultaneously — JWT in the public filter chain and Spring Session JDBC for the authenticated SecurityContext. The Spring Session layer has been removed in favor of pure stateless JWT (see SEAT-913 in release-notes.md). V65 attempted to drop these tables back in 2021 but Spring Session’s initialize-schema: always recreated them on every boot. V99 is the final drop, now that no code path re-creates them.

Downtime: None. The DROP TABLE runs in a standard Flyway transaction and completes in milliseconds; the tables were already small.

Rollback: Destructive. The tables cannot be restored from Flyway alone; a downgrade would need to run Spring Session’s schema init script by hand. Not recommended.

V100 — V100__seat_on_event_state_updated_at_partial_idx.sql

Adds a partial btree index on seat_on_event(state, updated_at DESC) WHERE state IN ('SOLD', 'LOCKED').

CREATE INDEX CONCURRENTLY IF NOT EXISTS seat_on_event_state_updated_at_idx
    ON seat_on_event (state, updated_at DESC)
    WHERE state IN ('SOLD', 'LOCKED');

A sibling V100__seat_on_event_state_updated_at_partial_idx.sql.conf file sets executeInTransaction=false so Flyway does not wrap the statement in a transaction (a requirement for CREATE INDEX CONCURRENTLY).

Context: every query behind the internal SaaS Fleet Grafana dashboard was doing a 4.5 GB Parallel Seq Scan over the full 20.9M-row seat_on_event table because there was no index on (state, updated_at). SOLD + LOCKED together account for only ~1.1 % of rows, so a partial index is ~6 MB. After V100 runs, every dashboard query flips from a ~1 s parallel seq scan to a sub-10 ms index scan.

Downtime: None. CREATE INDEX CONCURRENTLY does not take an ACCESS EXCLUSIVE lock on the table — reads and writes continue uninterrupted during the build. Expected build time on the 20.9M-row prod table: 30–90 seconds.

Idempotency: IF NOT EXISTS makes the statement safe to re-run. See the caveat below on CONCURRENTLY failure modes.

Rollback: Safe and cheap:

DROP INDEX CONCURRENTLY IF EXISTS seat_on_event_state_updated_at_idx;

Known edge case: if the Flyway migration is interrupted mid-build (pod eviction, OOM), Postgres can leave an INVALID index behind that does not serve queries but does add write overhead. Flyway will mark the migration as failed, and recovery requires:

  1. Manual DROP INDEX IF EXISTS seat_on_event_state_updated_at_idx; on prod.
  2. flyway repair to clear the failed migration row.
  3. Next editor-service restart re-runs V100.

Operators upgrading production should watch flyway_schema_history for the V100 row and \d seat_on_event to confirm the index is valid (INVALID marker is absent) after the first boot on the new version.

Expected Side Effects

All editor users signed out

Because Spring Session has been removed, any editor user who is currently logged in at the moment the new image rolls out loses their server-side SecurityContext on the next request and gets redirected to the login page. This is expected, one-time, and self-healing — they simply log back in.

No customer action required. There is no DB or Redis cleanup to do.

Verification: after the rollout, hit GET /actuator/health on editor-service and confirm it returns UP. Open the editor in a browser with a fresh session and confirm you can log in and perform an action.

Dependency audit warnings cleared

The CI Dependency Audit Editor Client and Dependency Audit Booking Client jobs were failing on every pipeline with two high-severity Vite CVEs (GHSA-v2wj-q39q-566r, GHSA-p9ff-h696-f583). Both are fixed by the bump to Vite 7.3.2 and the workspace-wide yarn resolutions override. Expect those jobs to go green on the first build after merge.

Monitoring & Alerting

New: SaaS Fleet Grafana dashboard

Internal only. Customers do not see this dashboard. It lives in the Seatmap Grafana folder on the internal cluster and queries the new analytics Postgres schema over the Hetzner vSwitch.

New: analytics schema on prod Postgres

10 read-only views in a dedicated schema, queried by a restricted seatmap_analytics role (SELECT-only, default_transaction_read_only = on, 30 s statement_timeout). Lives in products/db-migrations/manual/analytics-schema.sql as operational tooling, NOT as a Flyway migration — it is re-applied by hand when view definitions change so that a bad view does not block editor-service rollouts.

Self-hosted customers: this schema is not created on your clusters. It is internal Seatmap infrastructure for monitoring the SaaS fleet.

Deployment Steps

Standard zero-downtime rolling upgrade. No manual intervention required on customer clusters.

  1. Pull the new editor-service image tag.
  2. Flyway applies V99 and V100 on startup of the first replica. V100 runs CONCURRENTLY and completes in 30–90 s on a 20M-row table; earlier ones are typically much faster.
  3. Rolling restart of remaining replicas once the first one reports healthy.
  4. Existing editor users sign back in on their next request.

Rollback Plan

Rolling back editor-service is a normal image tag downgrade. Rolling back the database is more nuanced:

  • V100 (partial index): safe to drop with DROP INDEX CONCURRENTLY IF EXISTS seat_on_event_state_updated_at_idx;. No data change.
  • V99 (Spring Session tables): destructive. The tables were empty or stale-only anyway, but a downgrade image that still expects them would silently recreate them empty. Users would remain signed out until they log in again, which is the same state they would be in without the rollback.

Recommended: do not roll back V99. If 1.62.0 needs to be reverted, redeploy the previous image and let Spring Session recreate its schema on boot — state loss is identical to the rollout, so there is no advantage in running the DB restore.

  • Release Notes — product-level summary
  • CHANGELOG.md — full technical changelog
  • docs/VSWITCH_PRIVATE_ACCESS.md — internal runbook for the analytics-schema transport (SaaS operators only)