RPReleasePilot

ASTRYX

ASTRYX Asset Assignment Fix

Fixes asset assignment mismatch where assigned_to IDs exist but UI does not show assets as assigned.

readyHero demo

Risk assessment

What this is: A weighted score from release attributes (blast radius, migrations, auth/billing touchpoints). Higher means more review before deploy.

medium
Risk score64/ 100

Complete checklist, confirm rollback readiness, and use extended monitoring.

  • Production deployment+18
  • Database migration included+16
  • Multiple modules affected (3)+9
  • Medium test coverage signal+5
  • Medium blast radius+6

Context

Environment
production
Migration
Yes
Rollback
full

Checklist

Required checks: Gates that must be green before you can queue this release in the simulator.

  • DB migration reviewed with platformRequired

  • Canary metrics baseline capturedRequired

  • Rollback script dry-run on stagingRequired

Approvals

  • Alex Rivera (Engineering Lead)Approved
  • Jordan Kim (SRE)Approved

Affected modules

  • Inventory
  • Asset Assignment
  • User Directory

Rollback plan

Revert application deploy to previous stable tag; migration includes backward-compatible column defaults.

  1. Confirm read replica lag < 2s
  2. Redeploy tag v2.14.3-stable
  3. Run rollback migration script 2025-04-asset-assign-down.sql
  4. Verify asset assignment API returns expected assignments for sample tenants

Deployment simulation

Deterministic state machine — advances only when you click. Nothing provisions or deploys in the real world.

Current state: The timeline below reflects this run. After a rollback completes, use status updates and postmortem to document what happened.

Portfolio hero — ASTRYX Asset Assignment Fix

One click runs the scripted path through rollback recommended. Then use Start rollback → Complete rollback on this page, then generate status updates and postmortem below.

Pipeline overview

Pipeline phases (simulator). Current phase highlighted.

  1. Queued
  2. Preflight
  3. Deploying
  4. Verifying
  5. Monitoring
  6. Spike
  7. Rollback rec.
  8. Rolling back
  9. Restored
Current stateidle

Step detail

  1. Queue releasepending
  2. Verify approvalspending
  3. Check rollback planpending
  4. Run testspending
  5. Apply migration (if applicable)pending
  6. Deploy buildpending
  7. Verify health checkspending
  8. Monitor error ratepending
  9. Complete or escalatepending

Verification checks

Synthetic signals: Mock pass / warn / fail used to drive the story (e.g. error-rate spike). Not connected to live monitoring.

  • API healthpass
  • Assignment consistency samplepass
  • Error rate vs baselinepending

Related incidents

SEV-2resolved

Elevated Error Rate After Asset Release

Service ASTRYX Inventory

Verification detected elevated 500s after release.

Related release →Postmortem →

Status updates

Template-generated — internal, customer-facing, and executive variants from current release context.

What this does: Fills three comms drafts you can copy — useful after rollback or during an incident.

No status update generated yet. Use "Generate status update" after an incident or deployment event.

Postmortem

After rollback or a linked incident, generate a structured postmortem draft from templates.

What this does: Builds sections (summary, impact, timeline, RC, actions) from seeded incident data — a starting point for a real review doc.

Consolidated view: /postmortems

Audit trail (this session)