1. Release Notes
  2. Release 1.67.0

Deployment & Settings Changes - v1.67.0

Release: v1.67.0 Date: 2026-06-10

Summary

Impact Level: MEDIUM

Action Required: NO for the core app (migrations auto-apply); YES for the analytics view (manual)

Backward Compatible: YES

Quick Decision Matrix

Component/Area Change Type Risk Level Action Required Impact
Environment Variables No changes NONE NO -
Database Schema Migrations (V106 + V107) LOW NO Two additive migrations; auto-applied on editor-service startup
Analytics Schema New view v_org_ptd_usage LOW YES (manual) Recreated via seatmap_analytics role from manual/analytics-schema.sql
Application Config Redis command timeout (3s) LOW NO Editor and booking services fail fast on Redis stalls instead of hanging the request
Docker Images Standard upgrade NONE NO Tag bump only
Kubernetes/Helm No changes NONE NO No value changes for the editor, booking, or converter charts
Admin API New plan/billing endpoints LOW NO New admin-only plan and tenant endpoints; no change to existing public endpoints
Runtime Dependencies No changes NONE NO -

Deployment Decision

Overall Risk: LOW

Recommended Action: APPROVE

Downtime Required: NO - zero-downtime rolling restart supported.

Rollback Risk: SAFE - V106 and V107 are additive (new table, new column, new nullable FK). Downgrading editor-service with the new objects present is safe; unused columns and tables are ignored.

Special Considerations: The analytics view must be applied manually with the seatmap_analytics role.

Configuration Changes

Application Config

A Redis command timeout is now set for the editor and booking services so that a slow or stalled cache fails fast instead of blocking the request thread (SEAT-973):

data.redis.timeout: 3s

This is delivered via the chart defaults; no operator action is required. The save path treats post-commit cache eviction as best-effort, and booking-service compresses cached seatmaps to reduce memory pressure.

Environment Variables

No environment variables changed for the editor, booking, or converter services.

Database Changes

Two Flyway migrations run automatically on editor-service startup. Booking-service does not run migrations and is unaffected.

V106__create_schema_update_request_log.sql

Additive forensic logging for failed schema-update requests (SEAT-973).

New schema_update_request_log table - append-only capture of schema-save attempts:

  • id BIGSERIAL PRIMARY KEY, created_at TIMESTAMPTZ NOT NULL.
  • Context columns: schema_id, org_id, user_id, username, http_method, request_uri, http_status.
  • Payload columns: request_body JSONB, request_body_raw TEXT, exception TEXT, exported_seatmap TEXT.
  • Six covering indexes on (schema_id|org_id|user_id|http_status|request_uri, created_at DESC) and (created_at DESC) for diagnosis queries.

No existing tables are modified.

V107__plan_and_billing_period.sql

Additive schema for org plan capacity and billing period (SEAT-1027).

New plan table:

  • id BIGINT PRIMARY KEY, name VARCHAR(255) NOT NULL, capacity BIGINT NOT NULL DEFAULT 0, audit columns (created_at, updated_at, created_by_id, modified_by_id).
  • plan_id_seq sequence and a unique index on name.

organization:

  • plan_id BIGINT - nullable FK to plan(id) (constraint fk_organization_plan).
  • billing_period_start DATE - nullable.

Both additions are nullable, so existing organizations are unaffected until a plan is assigned.

Analytics view (manual)

manual/analytics-schema.sql adds CREATE OR REPLACE VIEW analytics.v_org_ptd_usage (period-to-date usage per org). Apply manually with the seatmap_analytics role - it is not part of the Flyway set and does not run on startup.

Kubernetes / Helm Changes

No changes to the editor, booking, or converter Helm values.

Admin API

New admin-only endpoints back the plan/billing feature (SEAT-1027): plan listing/creation, plan assignment to organizations, and tenant org listing. These live under the existing admin surface and require admin authentication. No existing public endpoint changed. See booking-service-api.md for the renderer-facing data changes.

CI/CD Deployment

Deployed through the standard GitLab CI/CD + Flux flow:

  1. Merge to dev - auto-deploys to stage via Flux reconciliation.
  2. Merge to main - manual trigger to production.

Zero-Downtime: Supported. Action Required: apply the analytics view manually; everything else is automated.

Rollback

Rollback Support: Automated via GitLab CI/CD (redeploy previous image tags).

Database Rollback: Not required - V106/V107 are additive and safe to leave in place when downgrading the service.

Procedure: Roll back the editor/booking image tags. The new table, column, FK, and analytics view are inert for older code.

Sign-Off

Deployment Risk: LOW

Rollback Safety: SAFE

Downtime Required: NO

Special Steps: Apply analytics.v_org_ptd_usage manually with the seatmap_analytics role.