Deleting Pull Request Attachments Prevents Reading Attachments
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Beginne mit delete_attachment_bug.py und den Aufrufen von GitClient create_attachment und delete_attachment und reproduziere anschließend die Sequenz in der Python-Shell. Vergleiche die Requests und die zurückgegebenen Attachment-URLs nach dem Löschen, um festzustellen, ob der Client oder die Azure DevOps API die FileIdNotFoundException verursacht. Fertig ist die Aufgabe, wenn die Ursache festgestellt ist und nicht gelöschte Attachments nach der Sequenz lesbar bleiben.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Hello,
I recently ran in to this issue while attempting to manage pull request attachments. It could be a bug with the AZDO API, but I'm specifically using azure-devops-python-api.
Steps to Reproduce
- Create multiple pull request attachments via
GitClient, and delete at least one. The specific order doesn't matter; you can create two attachments then delete one of them, or create a single attachment, delete it, and create a second attachment. - Attempting to access any non-deleted attachment (via the attachment URL) results in the following error:
{
"$id": "1",
"innerException": null,
"message": "TF400714: File ID 123456789 not found.",
"typeName": "Microsoft.TeamFoundation.Framework.Server.FileIdNotFoundException, Microsoft.TeamFoundation.Framework.Server",
"typeKey": "FileIdNotFoundException",
"errorCode": 0,
"eventId": 4005
}
Example Code
delete_attachment_bug.py
from azure.devops.v7_0.git.models import *
from azure.devops.v7_0.git.git_client import GitClient
from msrest.authentication import BasicAuthentication
from azure.devops.connection import Connection
from random import randint
import os
def fix_create_attachment(client: GitClient):
"""
See https://github.com/microsoft/azure-devops-python-api/issues/322 for documentation of this issue.
"""
def create_attachment(upload_stream, file_name, repository_id, pull_request_id, project=None):
route_values = {}
if project is not None:
route_values['project'] = client._serialize.url('project', project, 'str')
if file_name is not None:
route_values['fileName'] = client._serialize.url('file_name', file_name, 'str')
if repository_id is not None:
route_values['repositoryId'] = client._serialize.url('repository_id', repository_id, 'str')
if pull_request_id is not None:
route_values['pullRequestId'] = client._serialize.url('pull_request_id', pull_request_id, 'int')
# content = self._client.stream_upload(upload_stream, callback=callback)
response = client._send(http_method='POST',
location_id='965d9361-878b-413b-a494-45d5b5fd8ab7',
version='7.0',
route_values=route_values,
content=upload_stream.read(),
media_type='application/octet-stream')
return client._deserialize('Attachment', response)
client.create_attachment = create_attachment
pat = os.environ.get("mypersonalaccesstoken")
auth = BasicAuthentication("", pat)
connection = Connection("https://dev.azure.com/someorganization/", auth)
client: GitClient = connection.clients.get_git_client()
fix_create_attachment(client)
pr_id = 123456
project_id = "MyProject"
repo_id = "MyRepo"
def create_attachment():
with open("cool_pic.png", "rb") as file:
# Create random name for attachment
name = f"{randint(0,10000)}.png"
attachment: Attachment = client.create_attachment(file, name, repo_id, pr_id, project_id)
print(f"Created attachment: {name}\n(URL: {attachment.url})")
def delete_attachment(name):
client.delete_attachment(name, repo_id, pr_id, project_id)
print(f"Deleted attachment: {name}")
This code can be used along with the Python shell to reproduce the issue:
python -i delete_attachment_bug.py
>>> create_attachment()
>>> delete_attachment("nameFromPreviousCall")
>>> create_attachment()
Trying to access the most recently created attachment (via the attachment URL) results in the above error.
I'm using Python 3.7.4 and azure-devops==7.1.0b4.
I haven't been able to find a workaround yet. Note the example code includes a workaround for #322.
- Vorherrschende Sprache
- Python
- Sterne
- 684
- Forks
- 218
- Ø Merge
- 8 T. 10 Std.
- Gemergte PRs (30 T.)
- 1
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus microsoft/azure-devops-python-api
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 55/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 55/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
Alle Issues in microsoft/azure-devops-python-api
Ähnliche Issues
-
agent-ready documentation needs-triage
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 88/100
-
documentation
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 92/100
-
instance instance add
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 72/100
searxng/searx-instances#939 · 1 Kommentar ·
-
area-deployment area-integrations triage:bot-seen
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 86/100