CCPEDIAby Unity Nodes
ReleasesSplice 0.6.8

Splice 0.6.8

Digital AssetSplice

The migration.id value was removed from the SV helm charts (sv, validator, scan apps). These apps now resolve the synchronizer migration id automatically at start-up from their database. A freshly joining scan that does…

Open the release notes (opens in a new tab)docs.canton.network
  • Deployment
    • SV
      • The migration.id value was removed from the SV helm charts (sv, validator, scan apps). These apps now resolve the synchronizer migration id automatically at start-up from their database. A freshly joining scan that does not yet have any migration id in its database bootstraps it from the scan of the SV sponsoring the onboarding, configured via the new optional sponsorScanUrl value in the scan helm chart.
      • Increase sv-app default memory requests from 3Gi to 6Gi to ensure the max heap size fits in the requests and to avoid OOM evictions.
      • The splice-participant helm chart now refuses to create the participant database if another database whose name starts with participant already exists, guarding against accidentally creating a new participant database on a non-fresh deployment (e.g. due to a misconfigured persistence.databaseName). A participant database should only be created during a fresh deployment. This safety check can be disabled by setting the new persistence.enableParticipantDbConflictCheck helm value to false.
    • Validator
      • The migration.id value was removed from the validator (validator app) helm chart. For docker-compose deployments the -m <migration_id> flag of the validator start.sh script is now optional (if you deployed your validator before this change you must keep this flag set to the existing value). The validator resolves the synchronizer migration id automatically at start-up from its database. The migration id is now only used to name the participant database for backwards compatibility: if provided, the database participant-<migration_id> is used (set this to the migration id you previously deployed with); if omitted, the database participant is used, which is recommended for new deployments.
      • The splice-participant helm chart now refuses to create the participant database if another database whose name starts with participant already exists, guarding against accidentally creating a new participant database on a non-fresh deployment (e.g. due to a misconfigured persistence.databaseName). A participant database should only be created during a fresh deployment. This safety check can be disabled by setting the new persistence.enableParticipantDbConflictCheck helm value to false.
      • For docker-compose deployments, the Postgres entrypoint now refuses to create a participant database if another database whose name starts with participant already exists, guarding against accidentally creating a new participant database on a non-fresh deployment (e.g. due to a misconfigured -m <migration_id>). A participant database should only be created during a fresh deployment. This safety check can be disabled by passing the new -k flag to the validator start.sh script.
The migration id must still be kept for participant database naming for backwards compatibility (persistence.databaseName helm value, CANTON_PARTICIPANT_POSTGRES_DB docker compose env variable) to ensure the participant uses the currently configured database.For docker-compose validator deployments, pass the same -m <migration_id> you previously deployed with to keep using the existing participant-<migration_id> database, or omit it on new deployments to use the participant database.
  • Scan
    • The following deprecated endpoints have been removed from the public API:
      • /v0/activities
  • Bug fixes
    • Validator
      • Fixed a bug where validators using the bft-custom scan client configuration would incorrectly attempt to establish scan connections with all scan nodes during the validator startup. The scan client now strictly confines all scan connections to configured, trusted SV endpoints.
← All Splice releases