Splice 0.6.3
The app_activity_record_store table has been modified to avoid unexpected DB performance issues. Upon upgrade to this version, the existing data in this table which has been ingested since the 0.5.18 release will be…
- A newer release in the 0.6 line: Splice 0.6.14
- Newest Splice: Splice 0.9.4
Open the release notes (opens in a new tab)docs.canton.network
-
Scan app
- The
app_activity_record_storetable has been modified to avoid unexpected DB performance issues. Upon upgrade to this version, the existing data in this table which has been ingested since the0.5.18release will be deleted in order to support that. This impacts the data being served via the experimental fieldapp_activity_recordson the/v0/eventsand/v0/events/{update_id}endpoints. Specifically theapp_activity_recordsfield will not contain the data which has been provided for the events which happened between the0.5.18and this release. Note that theapp_activity_recordsdata already provided for events during this period is correct and the network explorers who have ingested this data should keep a copy of it. - Add
/v1/holdings/summaryendpoint that drops theaccumulated_holding_fees_unlocked,accumulated_holding_fees_locked,accumulated_holding_fees_total, andtotal_available_coinresponse fields and theas_of_roundrequest parameter, as those values are not meaningful aggregates. The same endpoint is also exposed on the validator scan-proxy. The/v0/holdings/summaryendpoint is now deprecated but remains available.
- The
-
SV app
-
Bump the minimum DAR versions to the ones from splice 0.5.7 which introduced the development fund manager as downgrades to earlier versions already fail. SV app automation will unvet those on the SV nodes.
The concrete versions are:
- Fix an issue where onboarding a new SV could fail when importing the ACS snapshot due to a vetting issue.
-
Bump the minimum DAR versions to the ones from splice 0.5.7 which introduced the development fund manager as downgrades to earlier versions already fail. SV app automation will unvet those on the SV nodes.
The concrete versions are:
-
SV deployment
- Update
participantAddressinscan-values.yamlandsv-validator-values.yamlto use the participant address without a migration suffix. Ensure that you override this with the correct helm install name for the participant or reinstall the participant without a migration suffix. - CometBFT: increased resource requests from 2 CPU and 5Gi to 3 CPUs and 7Gi, and the limit from 8Gi to 10Gi to better fit observed resource usage.
- Update