Skip to main content

Upgrades and Rollback

Treat a TradeScript upgrade as a matched release, not an isolated package change. The application bundle, customer SDK artifact, styles, worker assets, customer build fingerprint, and deployment lease must describe the same candidate build.

Upgrade one matched unit​

Release partWhy it must match
Application bundleContains the host integration compiled against the candidate public API
Customer SDK package and stylesProvide the runtime and visual assets for the exact version
Worker filesMust come from the same package build as the main runtime
Customer build fingerprintIdentifies the customer artifact during lease exchange and browser verification
Deployment leaseAuthorizes that fingerprint, SDK version, origin, and capability policy

Do not deploy a new package while continuing to request leases for the previous fingerprint. Do not roll back only the JavaScript bundle while leaving candidate worker files or authorization configuration in place.

1. Review the release before installing it​

Read the Release notes and classify every entry that affects your enabled datafeed, broker, storage, worker, UI, or agentic surface. TradeScript Pro Charts is pre-GA at 0.x: patch releases preserve the public API, while a minor release may include a clearly labelled breaking change and migration action.

Confirm with your TradeScript deployment contact:

  • the exact candidate package and SDK version;
  • the candidate customer build fingerprint;
  • any origin, entitlement, limit, or credential change; and
  • whether the previous build remains authorized for the rollback window.

2. Stage current and candidate authorization separately​

Build the candidate application with the candidate customer artifact and matching worker files. Configure the backend to exchange and cache leases under the candidate build fingerprint without replacing the current production cache entry.

Each application artifact must request or receive only its matching lease. This allows current and candidate sessions to overlap during a gradual or blue-green release.

3. Verify the candidate artifact​

Deploy the candidate to an approved origin and run Verify your deployment. Exercise every enabled integration, failure state, and cleanup path affected by the release notes.

Record the candidate application version, SDK version, build fingerprint, origin, worker configuration, lease expiry, and verification result. Never record the complete lease or permanent credential.

4. Promote and observe​

Promote the exact artifact you verified. Confirm that new sessions receive the candidate build and its matching lease, while sessions on the previous build continue to receive a valid previous-build lease during the overlap window.

Watch authorization, mount, datafeed, worker, storage, trading, and teardown signals. A successful deployment status is not sufficient if the live release identity or user journey differs from the verified candidate.

5. Roll back as one unit​

If the candidate fails:

  1. Restore the previous application artifact, customer SDK, styles, and worker files together.
  2. Route that artifact to the previous build fingerprint and a valid matching lease.
  3. Confirm the live release identity is the previous verified identity.
  4. Repeat the highest-risk verification rows and the original failing journey.
  5. Keep the candidate evidence for diagnosis; do not mutate it and call the result the previously verified build.

If the previous build is no longer authorized or its deployment record has changed, coordinate a matching authorization recovery with TradeScript rather than pairing it with the candidate lease.

Completion checklist​

  • The release notes and required migrations were reviewed before installation.
  • Current and candidate fingerprints use separate lease cache entries.
  • The candidate package, styles, workers, fingerprint, and lease match.
  • The deployed artifact—not only a development build—passed verification.
  • Monitoring confirms the promoted release identity and user journeys.
  • Rollback restores the complete previous matched unit.
  • Expired or retired build authorization is removed after the rollback window.

Next steps​