...
For SYNPY issues the fixed version to validate can be obtained by following the instructions under Validation here: /wiki/spaces/SYNPY/pages/643498030
A note on the use of staging.synapse.org: This instance of Synapse is separate from the production version (synapse.org) with which content is synchronized by the Synapse data migrator. For example if, in the course of testing a fix or new feature on staging, you create a new project, the project will be removed by the migrator before staging goes live as the new production. This gives validators some latitude to "tinker" on staging, knowing that any changes will be automatically cleaned up. While the two instances of Synapse are largely independent, they do share an underlying S3 bucket: Since the bucket contains hundreds of TB of data, it's not feasible to make a new copy each week. This means that any operations on staging that change bucket content will not be reverted by the migrator. Since Synapse treats bucket objects (files) as immutable, most operations don't change bucket content. The exception is the deletion (as opposed to 'trashing') of an entity by its owner. If you delete a file or table that you own on staging, it will be permanently deleted. The web browser only provides trashing of files and tables, so using staging through the browser does not pose a risk. But using the Python, R or CLI client, and opting to skip the trash can when deleting an entity, does mean that the underlying S3 object will be deleted in production. Therefore validators should refrain from deleting (without trashing) production data on staging when using the non-browser client to validate Synapse features.
| Info |
|---|
Related articles
| Filter by label (Content by label) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...