🐛 Ensure supported DID before calling Rotate

[ff137]

Resolves #3379 and #3381

---

I'm open to alternatives. I first thought to just call DID.validate, and raise BadRequest if that fails, but since ensure_supported_did is called downstream, and the client would not immediately know if the DID is unresolvable, I figured that everything may as well be validated in the route, before being sent to the RotateHandler.

That means ensure_supported_did will now be called twice. Perhaps the 2nd call can now be removed, since it's now just called earlier. Open to suggestions

[ff137]

My attempted solution, when passing a qualified did sov, results in:

  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/protocols/did_rotate/v1_0/routes.py", line 73, in rotate
    await did_rotate_mgr.ensure_supported_did(to_did)
  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/protocols/did_rotate/v1_0/manager.py", line 242, in ensure_supported_did
    await resolver.resolve(self.profile, did)
  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/did_resolver.py", line 87, in resolve
    _, doc = await self._resolve(profile, did, service_accept, timeout=timeout)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/did_resolver.py", line 63, in _resolve
    document = await asyncio.wait_for(
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 520, in wait_for
    return await fut
           ^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/base.py", line 161, in resolve
    result = await self._resolve(profile, did, service_accept)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/default/indy.py", line 185, in _resolve
    vmethod = builder.verification_method.add(
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/pydid/doc/builder.py", line 50, in add
    vmethod = type_.make(id=self._did.ref(ident), controller=controller, **kwargs)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/pydid/resource.py", line 101, in make
    return cls(**kwargs)
           ^^^^^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/pydid/verification_method.py", line 57, in __init__
    super().__init__(**data)
  File "/home/aries/.local/lib/python3.12/site-packages/pydantic/main.py", line 214, in __init__
    validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pydantic_core._pydantic_core.ValidationError: 1 validation error for Ed25519VerificationKey2018
public_key_base58
  Input should be a valid string [type=string_type, input_value=None, input_type=NoneType]

...

Seems this is the scenario for a did:sov that's not posted to the ledger

Everything seems to work fine for did:peer:2 and did:peer:4. did:key returns an unresolvable didcomm service problem report. Will investigate more, and try improve some things

[ff137]

RotateAck is not correctly configured. Somewhere it is trying to load class "Ack", instead of RotateAck:

"/home/aries/.local/lib/python3.12/site-packages/acapy_agent/utils/classloader.py", line 234, in resolved
    DeferLoad._class_cache[self._cls_path] = ClassLoader.load_class(
                                             ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/utils/classloader.py", line 125, in load_class
    raise ClassNotFoundError(
acapy_agent.utils.classloader.ClassNotFoundError: Class 'Ack' not defined in module: acapy_agent.protocols.did_rotate.v1_0.messages.ack

Found it here: 6bf8fc8

[ff137]

@jamshale @dbluhm just a headsup, it looks like the SonarCloud coverage analysis is broken. My coverage report locally shows all changes are covered, but SonarCloud gives 0%. Presumably relates to #3390

[jamshale]

@jamshale @dbluhm just a headsup, it looks like the SonarCloud coverage analysis is broken. My coverage report locally shows all changes are covered, but SonarCloud gives 0%. Presumably relates to #3390

I'll fix this. Something changed with github actions recently that broke this.

[dbluhm]

Overall looks pretty good. Quick nitpick on handling errors raised by pydid.

[jamshale]

👍

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud