Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConnectionManagerError / ConnectionProblemReport logic clash #2599

Closed
usingtechnology opened this issue Nov 8, 2023 · 0 comments · Fixed by #2600
Closed

ConnectionManagerError / ConnectionProblemReport logic clash #2599

usingtechnology opened this issue Nov 8, 2023 · 0 comments · Fixed by #2600
Assignees

Comments

@usingtechnology
Copy link
Contributor

Related to #2530 - how to handle orphaned/abandoned connections.

ConnectionManagerError are raised and generally initialized with a descriptive text (ex. "Connection DID does not match DIDDoc id"). Further into the flow, the handlers catch ConnectionManagerErrors then raise ConnectionProblemReport. However, ConnectionProblemReports require very specific enums to set their problem_code property. If the ConnectionManagerError.error_code (the descriptive string) is used as the ConnectionProblemReport.problem_code the schema validation will fail.

So, long story short, when we think we are raising ConnectionProblemReports and sending them to be handled, they actually are not created/handled because they fail schema validation and are not created. We need to go through these and ensure the errors are passed properly and get handled as expected.

Another part of this is ConnectionProblemReports use AgentMessage as the base class while DIDExchangeProblemReport uses the ProblemReport as a base class. We should be consistent and update ConnectionProblemReport to follow DIDExchangeProblemReport "standard".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant