Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow filtering and cascade delete of artifacts #5226

Closed
tothegills opened this issue Jan 18, 2019 · 4 comments
Closed

Slow filtering and cascade delete of artifacts #5226

tothegills opened this issue Jan 18, 2019 · 4 comments
Assignees
Labels
feature/performance kind/enhancement This issue represents an enhancement we are committed to adding to Octopus as some time tag/breaking-change The resolution of this issue introduced a deliberately breaking change
Milestone

Comments

@tothegills
Copy link
Contributor

tothegills commented Jan 18, 2019

Artifacts have a RelatedDocumentIds column which is heavily used when filtering artifacts and performing cascade deletes. When there are many artifacts this causes performance issues.

See (private) https://secure.helpscout.net/conversation/725419228/36379
Related to #4319

@tothegills tothegills added kind/enhancement This issue represents an enhancement we are committed to adding to Octopus as some time feature/performance labels Jan 18, 2019
@tothegills tothegills self-assigned this Jan 18, 2019
@tothegills tothegills added this to the 2019.1.0 milestone Jan 25, 2019
@tothegills
Copy link
Contributor Author

tothegills commented Jan 25, 2019

Release note: Breaking change Increased the speed of artifact retrieval and cascade deletion when there are many artifacts

@tothegills
Copy link
Contributor Author

tothegills commented Jan 25, 2019

The breaking change relates to the Octopus API and OctopusClient. The /api/artifacts endpoint no longer returns RelatedDocumentIds and instead returns ServerTaskId. For the client, ArtifactResource no longer has a field called RelatedDocumentIds, instead it has a field called ServerTaskId. ServerTaskId is the id of the server task that collected the artifact.

@tothegills
Copy link
Contributor Author

Data Migration Errors
The upgrade script that migrates data as a part of this changes expects that artifacts are associated with a task. When artifacts are collected during a deployment this is done automatically. For artifacts that have been created using the Octopus server API there is a chance that the artifact was created without an associated task. When that is the case, the upgrade script will fail with a message:

The upgrade script is unable to process the artifact with id Artifacts-1, the upgrade has been halted.
See the issue at https://github.com/OctopusDeploy/Issues/issues/5226 for more information about why this error was encountered and common workarounds.
Please re-install the version of Octopus Deploy that you are upgrading from and get in touch with support@octopus.com providing the following information:
Unable to migrate artifact with id Artifacts-1. Expected to find one ServerTask in RelatedDocumentIds. RelatedDocumentIds are ...

You can find all artifacts that have been created without an associated task by running the following SQL query:

SELECT *
FROM [dbo].[Artifact]
WHERE [RelatedDocumentIds] NOT LIKE '%ServerTasks%'

If you do not need the artifacts, the easiest approach is to delete them by running the following SQL:

DELETE
FROM [dbo].[Artifact]
WHERE [RelatedDocumentIds] NOT LIKE '%ServerTasks%'

If you do need the artifacts and would like to associate them with the relevant task there should be a release or deployment id in the RelatedDocumentIds column. If that is the case get in touch with support@octopus.com and we can provide a script to run pre-migration.

@lock
Copy link

lock bot commented Jul 15, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 15, 2019
@zentron zentron added the tag/breaking-change The resolution of this issue introduced a deliberately breaking change label Jan 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature/performance kind/enhancement This issue represents an enhancement we are committed to adding to Octopus as some time tag/breaking-change The resolution of this issue introduced a deliberately breaking change
Projects
None yet
Development

No branches or pull requests

2 participants