internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: hyperledger/aries-cloudagent-python

Issue:
Remove invalid/corrupted tails files
When acapy attempts to download a tails file (e.g. for revoking/issuing a credential), it will attempt to download the file from the public URI. If this process fails, (e.g. the tails server is temporarily unavailable and answers with an error code), then acapy will download the file, check for a valid hash (this check fails) and does not remove the tails file if an invalid hash value is detected.

The next time the tails file is required, acapy will use the invalid file in the filesystem (resulting in errors in indy-sdk/ursa) instead of attempting a redownload.




Discussion:

Resolving patch:
diff --git a/aries_cloudagent/revocation/models/revocation_registry.py b/aries_cloudagent/revocation/models/revocation_registry.py
--- a/aries_cloudagent/revocation/models/revocation_registry.py
+++ b/aries_cloudagent/revocation/models/revocation_registry.py
@@ -1,6 +1,7 @@
 """Classes for managing a revocation registry."""
-
+import http
 import logging
+import os
 import re
 
 from os.path import join
@@ -169,23 +170,33 @@ async def retrieve_tails(self):
             tails_file_dir.mkdir(parents=True)
 
         buffer_size = 65536  # should be multiple of 32 bytes for sha256
+        file_hasher = hashlib.sha256()
         with open(tails_file_path, "wb", buffer_size) as tails_file:
-            file_hasher = hashlib.sha256()
-
             with Session() as req_session:
                 try:
                     resp = req_session.get(self._tails_public_uri, stream=True)
+                    # Should this directly raise an Error?
+                    if resp.status_code != http.HTTPStatus.OK:
+                        LOGGER.warning(
+                            f"Unexpected status code for tails file: {resp.status_code}"
+                        )
                     for buf in resp.iter_content(chunk_size=buffer_size):
                         tails_file.write(buf)
                         file_hasher.update(buf)
                 except RequestException as rx:
                     raise RevocationError(f"Error retrieving tails file: {rx}")
 
-            download_tails_hash = base58.b58encode(file_hasher.digest()).decode("utf-8")
-            if download_tails_hash != self.tails_hash:
-                raise RevocationError(
-                    "The hash of the downloaded tails file does not match."
-                )
+        download_tails_hash = base58.b58encode(file_hasher.digest()).decode("utf-8")
+        if download_tails_hash != self.tails_hash:
+            try:
+                os.remove(tails_file_path)
+                tails_file_dir.rmdir()
+            except OSError as err:
+                LOGGER.warning(f"Could not delete invalid tails file: {err}")
+
+            raise RevocationError(
+                "The hash of the downloaded tails file does not match."
+            )
 
         self.tails_local_path = tails_file_path
         return self.tails_local_path


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
connection error when using public did invitation
We used public did invitation well.
But, recent changes occur connection error.

```
  File "/Users/baegjae/src/aries-cloudagent-python/aries_cloudagent/protocols/connections/v1_0/manager.py", line 1103, in get_connection_targets
    targets = await self.fetch_connection_targets(connection)
  File "/Users/baegjae/src/aries-cloudagent-python/aries_cloudagent/connections/base_manager.py", line 340, in fetch_connection_targets
    label=invitation.label if invitation else None,
UnboundLocalError: local variable 'endpoint' referenced before assignment
```
Above is part of the error log.

I debugged and I found that below line makes error when using public did invitation.
https://github.com/hyperledger/aries-cloudagent-python/blob/3751b61d6774185bec42315ddb084ec44c219fd3/aries_cloudagent/connections/base_manager.py#L290

In here, `connection.invitation_msg_id` and `connection.invitation_key` were `None` when using public did invitation.
Therefore, `if invitation.did:` code not worked.

Thanks!


Discussion:
I think this one is for you @shaangill025 

Resolving patch:
diff --git a/aries_cloudagent/connections/base_manager.py b/aries_cloudagent/connections/base_manager.py
--- a/aries_cloudagent/connections/base_manager.py
+++ b/aries_cloudagent/connections/base_manager.py
@@ -287,7 +287,11 @@ async def fetch_connection_targets(
             in (ConnRecord.State.INVITATION, ConnRecord.State.REQUEST)
             and ConnRecord.Role.get(connection.their_role) is ConnRecord.Role.RESPONDER
         ):
-            if connection.invitation_msg_id or connection.invitation_key:
+            if (
+                connection.invitation_msg_id
+                or connection.invitation_key
+                or not connection.their_did
+            ):
                 invitation = await connection.retrieve_invitation(self._session)
                 if isinstance(
                     invitation, ConnectionInvitation


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
Configuration endpoint exposes wallet storage credentials
Admin server endpoint ` /server/config` exposes `wallet.storage_creds`.

Reason is a typo in line https://github.com/hyperledger/aries-cloudagent-python/blob/52960be1ca87fbb3b48eef9a737e297c8eb5cff9/aries_cloudagent/admin/server.py#L578

should be `wallet.storage_creds`


Discussion:

Resolving patch:
diff --git a/aries_cloudagent/admin/server.py b/aries_cloudagent/admin/server.py
--- a/aries_cloudagent/admin/server.py
+++ b/aries_cloudagent/admin/server.py
@@ -575,7 +575,7 @@ async def config_handler(self, request: web.BaseRequest):
                 "wallet.key",
                 "wallet.rekey",
                 "wallet.seed",
-                "wallet.storage.creds",
+                "wallet.storage_creds",
             ]
         }
         for index in range(len(config.get("admin.webhook_urls", []))):


Test patch:
diff --git a/aries_cloudagent/admin/tests/test_admin_server.py b/aries_cloudagent/admin/tests/test_admin_server.py
--- a/aries_cloudagent/admin/tests/test_admin_server.py
+++ b/aries_cloudagent/admin/tests/test_admin_server.py
@@ -373,7 +373,7 @@ async def test_query_config(self):
                     "wallet.key",
                     "wallet.rekey",
                     "wallet.seed",
-                    "wallet.storage.creds",
+                    "wallet.storage_creds",
                 ]
             )
             assert config["admin.webhook_urls"] == [
Repository: hyperledger/aries-cloudagent-python

Issue:
did:web resolver: DIDWeb.PATTERN too permissive
The regular expression used for `DIDWeb.PATTERN` is currently too permissive causing other DIDs (such as `did:github:dbluhm`) to be pushed to the `did:web` resolver for handling.

The current value used is: `^(did:web:)?([a-zA-Z0-9%._-]*:)*[a-zA-Z0-9%._-]+$`

I'm not sure how this is used elsewhere but at least for resolver selection, I think the `?` on `(did:web:)` is the part causing us trouble. If the `did:web` part is intended to be optional for other uses, we might need to use a different regex for resolver selection. The resolver selection regex is really used only to sort out whether it should handle a given DID and does not need to be exhaustive. Further validation can be performed by the resolver itself after selection. `^did:web:.*$` would likely be sufficient.

@domwoe 


Discussion:
@Luis-GA same problem we were seeing for the Uniresolver plugin
ah, sorry! This was not intended. Will fix this later today.

Resolving patch:
diff --git a/aries_cloudagent/messaging/valid.py b/aries_cloudagent/messaging/valid.py
--- a/aries_cloudagent/messaging/valid.py
+++ b/aries_cloudagent/messaging/valid.py
@@ -228,7 +228,7 @@ class DIDWeb(Regexp):
     """Validate value against did:web specification."""
 
     EXAMPLE = "did:web:example.com"
-    PATTERN = re.compile(r"^(did:web:)?([a-zA-Z0-9%._-]*:)*[a-zA-Z0-9%._-]+$")
+    PATTERN = re.compile(r"^(did:web:)([a-zA-Z0-9%._-]*:)*[a-zA-Z0-9%._-]+$")
 
     def __init__(self):
         """Initializer."""


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
GET ​/present-proof​/records​/{pres_ex_id}​/credentials model doesn't match returned presentation_referents
Version  : 0.7.0

Description :
The model for `IndyCredPrecis` provides a field name of `pres_referents` however the returned response body for `GET ​/present-proof​/records​/{pres_ex_id}​/credentials` has the field called `presentation_referents`.  For code generation to work for any language these have to match .  Attaching a screen shot of from the Swagger UI showing the response and model.

![Screen Shot 2021-07-21 at 9 10 00 am](https://user-images.githubusercontent.com/63565402/126406537-9f997a96-ecda-437f-a55d-bbdc816c6032.png)
  
Originally I thought this also existed in 0.5.6 but I was wrong, it seems to have been changed between 0.5.6 and 0.7.0


Discussion:
I should point out that this is the result using the V1.0 interfaces. I haven't yet tried with the V2.0 interfaces.

Resolving patch:
diff --git a/aries_cloudagent/indy/models/cred_precis.py b/aries_cloudagent/indy/models/cred_precis.py
--- a/aries_cloudagent/indy/models/cred_precis.py
+++ b/aries_cloudagent/indy/models/cred_precis.py
@@ -92,7 +92,7 @@ class IndyCredPrecisSchema(OpenAPISchema):
         IndyNonRevocationIntervalSchema(),
         description="Non-revocation interval from presentation request",
     )
-    pres_referents = fields.List(  # aca-py augments with pres_referents
+    presentation_referents = fields.List(  # aca-py augments with pres_referents
         fields.Str(
             description="presentation referent",
             example="1_age_uuid",


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
Acme Controller Workshop: Unclear instructions for issuing work credential
I am working through the Acme Controller Workshop. First: A big thanks to everyone who contributed! I find it very easy to follow and I am learning a lot along the way.

One step left me scratching my head, though. In Section "Issuing Alice a Work Credential", what should I do with this piece of code?
``` python
        with log_timer("Publish schema and cred def duration:"):
            # define schema
            version = format(
                "%d.%d.%d"
                % (
                    random.randint(1, 101),
                    random.randint(1, 101),
                    random.randint(1, 101),
                )
            )
            # (schema_id, cred_def_id) = await agent.register_schema_and_creddef(
                "employee id schema",
                version,
                ["employee_id", "name", "date", "position"],
                support_revocation=False,
                revocation_registry_size=TAILS_FILE_COUNT,
            )
```
Should I copy-paste this? Where?


Discussion:
Hi @estrehle I think that is old code, I'll remove it from the instructions.

@ianco Thanks for getting back! I played around a bit and found out that I actually need to copy-paste this code right after the previous code bit. Otherwise we're missing a definition for `schema_id` and `cred_def_id` which are used later. I'll suggest a fix and create a PR.

Resolving patch:
diff --git a/demo/runners/acme.py b/demo/runners/acme.py
--- a/demo/runners/acme.py
+++ b/demo/runners/acme.py
@@ -136,7 +136,6 @@ async def main(args):
         )
 
         acme_agent.public_did = True
-        # TODO: Create schema
         # acme_schema_name = "employee id schema"
         # acme_schema_attrs = ["employee_id", "name", "date", "position"]
         await acme_agent.initialize(
@@ -145,6 +144,8 @@ async def main(args):
             # schema_attrs=acme_schema_attrs,
         )
 
+        # TODO publish schema and cred def
+
         # generate an invitation for Alice
         await acme_agent.generate_invitation(display_qr=True, wait=True)
 


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
Unable to filter for invitation from OOB invitations in multi-tenant environment
When creating an OOB invitation (whether it's with a public DID or not), there is not enough information returned to retrieve the specific invitation connection via the `/connections` API call. The Invitation's ID is returned in both calls and it could be used as a filter.

I plan on adding `invitation_msg_id` as a filter to `GET /connections`. Hoping to get this in for 0.7.4, @ianco 


Discussion:

Resolving patch:
diff --git a/aries_cloudagent/protocols/connections/v1_0/routes.py b/aries_cloudagent/protocols/connections/v1_0/routes.py
--- a/aries_cloudagent/protocols/connections/v1_0/routes.py
+++ b/aries_cloudagent/protocols/connections/v1_0/routes.py
@@ -205,6 +205,11 @@ class ConnectionsListQueryStringSchema(OpenAPISchema):
         ),
         example=ConnRecord.Protocol.RFC_0160.aries_protocol,
     )
+    invitation_msg_id = fields.UUID(
+        description="Identifier of the associated Invitation Mesage",
+        required=False,
+        example=UUIDFour.EXAMPLE,
+    )
 
 
 class CreateInvitationQueryStringSchema(OpenAPISchema):
@@ -336,6 +341,7 @@ async def connections_list(request: web.BaseRequest):
         "request_id",
         "invitation_key",
         "their_public_did",
+        "invitation_msg_id",
     ):
         if param_name in request.query and request.query[param_name] != "":
             tag_filter[param_name] = request.query[param_name]


Test patch:
diff --git a/aries_cloudagent/protocols/connections/v1_0/tests/test_routes.py b/aries_cloudagent/protocols/connections/v1_0/tests/test_routes.py
--- a/aries_cloudagent/protocols/connections/v1_0/tests/test_routes.py
+++ b/aries_cloudagent/protocols/connections/v1_0/tests/test_routes.py
@@ -33,6 +33,7 @@ async def test_connections_list(self):
             "connection_protocol": ConnRecord.Protocol.RFC_0160.aries_protocol,
             "invitation_key": "some-invitation-key",
             "their_public_did": "a_public_did",
+            "invitation_msg_id": "dummy_msg",
         }
 
         STATE_COMPLETED = ConnRecord.State.COMPLETED
@@ -94,6 +95,7 @@ async def test_connections_list(self):
                         "invitation_id": "dummy",
                         "invitation_key": "some-invitation-key",
                         "their_public_did": "a_public_did",
+                        "invitation_msg_id": "dummy_msg",
                     },
                     post_filter_positive={
                         "their_role": [v for v in ConnRecord.Role.REQUESTER.value],
Repository: hyperledger/aries-cloudagent-python

Issue:
Env_var ACAPY_PROMOTE-AUTHOR-DID is invalid with hyphen
Current behaviour:

The argparse `aries_cloudagent/config/argparse.py` defines the ACAPY_PROMOTE-AUTHOR-DID as an env var in ll. 1791. That is invalid when using an env file parsed to a container and the containers fails to start up entirely.

Suggested change:

Rename `ACAPY_PROMOTE-AUTHOR-DID` to `ACAPY_PROMOTE_AUTHOR_DID`

Expected behaviour:
`ACAPY_PROMOTE_AUTHOR_DID` can be set in an env file and `ACAPY_PROMOTE_AUTHOR_DID` get correctly picked up by aca-py. 



Discussion:

Resolving patch:
diff --git a/aries_cloudagent/config/argparse.py b/aries_cloudagent/config/argparse.py
--- a/aries_cloudagent/config/argparse.py
+++ b/aries_cloudagent/config/argparse.py
@@ -1837,7 +1837,7 @@ def add_arguments(self, parser: ArgumentParser):
         parser.add_argument(
             "--auto-promote-author-did",
             action="store_true",
-            env_var="ACAPY_PROMOTE-AUTHOR-DID",
+            env_var="ACAPY_AUTO_PROMOTE_AUTHOR_DID",
             help="For Authors, specify whether to automatically promote"
             " a DID to the wallet public DID after writing to the ledger.",
         )


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
Messages with an empty ~thread decorator
0.8.1 is sending messages with an empty `~thread`. 

This can confuse callers as [RFC 0008](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0008-message-id-and-threading) appears ambiguous; it states what to do if `~thread` has not `thid` and what to do if no `~thread`, but not what to do with `~thread` with no `thid`.

If ACA-Py has no data in the `~thread`, then let's not include it.

See https://github.com/hyperledger/aries-vcx/issues/875





Discussion:
After looking through ACA-Py code, it is pretty clear that `thid` is not always expected to be populated in a `~thread`, so I think we need to do this on a case-by-case basis. 

However, the code clearly shows that `thid` was intended to be populated for `credential-offer` and there is a bug here. I will file a PR to address that bug. 

Resolving patch:
diff --git a/aries_cloudagent/protocols/issue_credential/v1_0/manager.py b/aries_cloudagent/protocols/issue_credential/v1_0/manager.py
--- a/aries_cloudagent/protocols/issue_credential/v1_0/manager.py
+++ b/aries_cloudagent/protocols/issue_credential/v1_0/manager.py
@@ -309,7 +309,7 @@ async def _create(cred_def_id):
             offers_attach=[CredentialOffer.wrap_indy_offer(credential_offer)],
         )
 
-        credential_offer_message._thread = {"thid": cred_ex_record.thread_id}
+        credential_offer_message._thread = {"thid": credential_offer_message._thread_id}
         credential_offer_message.assign_trace_decorator(
             self._profile.settings, cred_ex_record.trace
         )


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
wallet-type: only "indy" creates DB and tables; "askar" missing
using version 0.10.4 we noticed that new Agents are force into in-memory wallets, not postgres. 

Leaving out `wallet-type:` in our config.yml results in an in-memory wallet, not the postgres wallet that we need.

setting `wallet-type: indy` gives us our storage but then dumps out a deprecation note:
```
2023-11-20 16:42:14 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
2023-11-20 16:42:14 ::                             ⚠ DEPRECATION NOTICE: ⚠                              ::
2023-11-20 16:42:14 :: -------------------------------------------------------------------------------- ::
2023-11-20 16:42:14 :: The Indy wallet type is deprecated, use Askar instead; see: https://aca-         ::
2023-11-20 16:42:14 :: py.org/main/deploying/IndySDKtoAskarMigration/                                   ::
2023-11-20 16:42:14 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
```

At one point there was a `wallet-type: askar` option but that has vanished it seems. Only `basic` (default) and `indy` are supported as options from what I can see:

```  
--wallet-type <wallet-type>
                        Specifies the type of Indy wallet provider to use. Supported internal storage types are 'basic' (memory) and 'indy'. The default (if not specified)
                        is 'basic'. [env var: ACAPY_WALLET_TYPE]
```


Discussion:
is it possible that the `wallet-storage-type: basic` has been confused with `wallet-type: askar` somehow?
`--wallet-type askar` will work; the help text is just out of date. I'll submit a quick update for that.

Resolving patch:
diff --git a/aries_cloudagent/config/argparse.py b/aries_cloudagent/config/argparse.py
--- a/aries_cloudagent/config/argparse.py
+++ b/aries_cloudagent/config/argparse.py
@@ -1574,9 +1574,9 @@ def add_arguments(self, parser: ArgumentParser):
             default="basic",
             env_var="ACAPY_WALLET_TYPE",
             help=(
-                "Specifies the type of Indy wallet provider to use. "
-                "Supported internal storage types are 'basic' (memory) and 'indy'. "
-                "The default (if not specified) is 'basic'."
+                "Specifies the type of wallet provider to use. "
+                "Supported internal storage types are 'basic' (memory) and 'askar'. "
+                "The default (if not specified) is 'basic'. 'indy' is deprecated."
             ),
         )
         parser.add_argument(
@@ -1586,7 +1586,7 @@ def add_arguments(self, parser: ArgumentParser):
             default="default",
             env_var="ACAPY_WALLET_STORAGE_TYPE",
             help=(
-                "Specifies the type of Indy wallet backend to use. "
+                "Specifies the type of wallet backend to use. "
                 "Supported internal storage types are 'basic' (memory), "
                 "'default' (sqlite), and 'postgres_storage'.  The default, "
                 "if not specified, is 'default'."


Test patch:
Repository: hyperledger/aries-cloudagent-python

Issue:
Regression(0.12.X): Revocation Notifications not getting emitted
It looks like #2558 introduced a bug where revocation notifications are no longer getting emitted when using the `/revocation/publish-revocations` endpoint. It seems to be fine when revocation is immediately published on revoke but if the issuer desires to batch them together and publish all pending revocations at once, no notifications are emitted to the holder connection.

This seems to be an issue in both 0.12.0 and 0.12.1rc0. Not sure why we didn't catch this one sooner :thinking: 


Discussion:
Actually no, it wasn't #2558; it looks like it was #2812. @jamshale it looks like we might have deleted some notification emissions from `aries_cloudagent/revocation/manager.py` so they could be handled in Askar-AnonCreds but maybe didn't account for the plain old Askar wallet case?
In particular, these lines: https://github.com/hyperledger/aries-cloudagent-python/pull/2812/files#diff-21df84291ab9a8290fcb3f396c10df170eb5c891236ad3a9dcbdec9df885749fL299-L302
I thought I removed this on purpose because I changed the flow to only notify after the revocation id's were written to the ledger instead of right when the endpoint was called. If this isn't happening, I must have messed something up. I can look. I thought I had covered this case.

Resolving patch:
diff --git a/aries_cloudagent/revocation/manager.py b/aries_cloudagent/revocation/manager.py
--- a/aries_cloudagent/revocation/manager.py
+++ b/aries_cloudagent/revocation/manager.py
@@ -256,6 +256,7 @@ async def publish_pending_revocations(
             if limit_crids:
                 crids = crids.intersection(limit_crids)
             if crids:
+                crids = list(crids)
                 (delta_json, failed_crids) = await issuer.revoke_credentials(
                     issuer_rr_rec.cred_def_id,
                     issuer_rr_rec.revoc_reg_id,
@@ -294,6 +295,9 @@ async def publish_pending_revocations(
                         )
                     else:
                         rev_entry_resp = await issuer_rr_upd.send_entry(self._profile)
+                        await notify_revocation_published_event(
+                            self._profile, issuer_rr_rec.revoc_reg_id, crids
+                        )
                 published = sorted(crid for crid in crids if crid not in failed_crids)
                 result[issuer_rr_rec.revoc_reg_id] = published
 


Test patch: