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

MatchamkeExtensionServer issues with single Data<Gathering> outputs #105

Open
EpicUsername12 opened this issue Apr 16, 2023 · 0 comments
Open
Labels

Comments

@EpicUsername12
Copy link
Contributor

EpicUsername12 commented Apr 16, 2023

The following methods have an implementation issue:

They all respond with a single Data<Gathering>

But in the python MatchmakeExtensionServer, the handler expects that:

response = await self.auto_matchmake_postpone(client, gathering, message)
#--- response ---
if not isinstance(response, common.Data):
raise RuntimeError("Expected common.Data, got %s" %response.__class__.__name__)
output.anydata(response)

This check is generated if and only if a method returns a single Data<T>, otherwise it just checks that the response contain the correct fields, with no typechecking.

So if the implementation returns a MatchmakeSession, it should be valid, but since it doesn't inherit from common.Data (but common.Structure, even though it's registered in the DataHolder list), this check fails, and the error is raised.

  • A quick manual fix is to remove the if case, and it works as expected since the Gathering types are all registered in the DataHolder

NOTE: This might be occuring in other protocols, but i didn't bother checking

So a long term fix may be to add a check in the generate_protocols.py script so it checks the object is of a type registered in the DataHolder registry instead of checking the response is an instance of common.Data, i'm waiting for your input on that.

@EpicUsername12 EpicUsername12 changed the title MatchamkeExtensionServer issues with Data<Gathering> outputs MatchamkeExtensionServer issues with single Data<Gathering> outputs Apr 16, 2023
@kinnay kinnay added the bug label Oct 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants