Deleting Pull Request Attachments Prevents Reading Attachments

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

1. 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.
2. 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.

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.