feat(vs-agent): add the receipts module to the v2 didcomm api

[tarunvadde]

Closes #659

• POST /v2/didcomm/receipts sends receipts on a connection and returns the sent message id.
• UNKNOWN_ID 404 for an unknown connection, and for a deployment that does not serve the module, which is only registered with the chat plugin.
• The module API returns void, so the controller builds the message through DidCommReceiptsService, same path the module takes internally, just keeping the id.

Two calls worth a look:

• It adds @2060.io/credo-ts-didcomm-receipts to apps/vs-agent, which had kept the chat packages behind optImport. VsAgentNestPlugin already takes a controllers array, so this could ship with the chat plugin instead and get the OPTIONAL 404 structurally. I followed the location the issue names.
• listProtocols is left out, it does not exist yet. Raised as Protocol Discovery and Basic Messages are missing from the v2 DIDComm API #683.

[lotharking]

This try/catch does not add any value here. The dependency manager's resolve method returns undefined when the service cannot be resolved, so there is no need to catch an exception in this case.

[tarunvadde]

Without the catch a deployment with no chat plugin gets a 500 instead of the 404 the module is meant to answer. But isRegistered is on the same interface and reads better, so I switched to that.

[lotharking]

Please review the listProtocols requirement, as it has not been implemented yet and is explicitly required by the issue.

[tarunvadde]

Left out on purpose, it does not exist yet. #666 carries the same task for seven more modules, so building it here would mean a hardcoded list that #666 rewrites. Raised it as #683.

[lotharking]

Why not use the existing unknownConnection function here?

[tarunvadde]

It was module-private in V2DidcommConnectionsController, so I could not import it. Promoted it to common/AdminApiError.ts and both controllers use it now.

[genaris]

I'd like to avoid the direct dependency on credo-ts-ext modules. I know that updating receipts module can take some more time, but I think that's the right way to do it. I have no problem if we use a patch in the meantime, but try to not add this redundant code on vs-agent.

[genaris]

So this reimplementing the whole DidCommReceiptsApi.send() just because is not returning the id?

I think the correct fix for this is open a PR on https://github.com/openwallet-foundation/credo-ts-didcomm-ext and, once implemented, just call agent.didcomm.receipts.send(). If VsAgent is properly typed, we won't need the direct dependency on @2060.io/credo-ts-didcomm-receipts.

[genaris]

We can do a direct check on the enabled chat modules rather than doing this indirectly (which also add a direct dependency on receipts credo-ts-ext module)

[tarunvadde]

I'd like to avoid the direct dependency on credo-ts-ext modules. I know that updating receipts module can take some more time, but I think that's the right way to do it. I have no problem if we use a patch in the meantime, but try to not add this redundant code on vs-agent.

Thanks and both fixed. The controller checks 'receipts' in agent.modules and calls agent.modules.receipts.send(), so nothing is reimplemented any more.

I raised openwallet-foundation/credo-ts-didcomm-ext#179 to make send() return the id, and patched it locally in the meantime as you suggested. MessageState is now declared in the DTO rather than imported, since [VSA-ADM-DC-RC] already fixes those five values, so apps/vs-agent has no direct dependency on the receipts module at all.

[genaris]

With the latest changes you've introduced, now the plugin stays an optionalDependency. The only plugin import is import type, and the endpoint degrades to a 404 when the module is absent.

One architectural note, to resolve in #692 rather than here: the receipts controller lives in the app, so the route is registered (and advertised in Swagger) even on deployments that do not serve the receipts module, and it needs the agent as unknown as VsAgent<ChatAgentModules> cast. In #692 we are converging on the pattern where plugin endpoints live in the plugin package and register through VsAgentNestPlugin.controllers (as the MRTD controller does there). Since #692 already touches this controller, let's move it into plugin-chat in that PR, together with the other chat-module controllers.

[tarunvadde]

Thanks. Merged main in, the conflict was the lockfile plus a duplicated patchedDependencies block that dropped the credo patches from #690. The receipts controller moved into plugin-chat in #692 as you asked.