Closed washeck closed 1 year ago
Wow, thank you very much for your contribution.
Passing the protocol at handler initialization is indeed a mistake... As you noticed, most users only have a single generic view, with only 1 entry point, supporting both protocols.
You spotted an important bug, thanks again !
Do you know why the build failed? I ran tox
locally and it passed.
The build failed because of a security rule. A token used to upload coverage result is not available to actions ran from codebase different from this one (typically, on a PR). This is something I need to address. I will in the next days, I won't have the time today. But your changes in the code are perfectly valid, no doubt all tests will pass. I will merge it ASAP.
I think the issue should be solved if you rebase your commit on top of 3756eef36c61677bf. Your PR should be automatically updated accordingly, and the actions workflow should now successfully finish
It failed again, due to pyenv installer failure. It seems I don't have the rights to re-run it.
Thanks for merging. Would you mind releasing a fix version? I think this bug could be surprising (and maybe with security implications) for some users.
Handler constructor expects to receive entrypoint name but it was given a protocol by mistake.
One of the end results was that when you don't specify protocol, Protocol.ALL is used which is the same string as "all entrypoints" making all methods available in all entrypoints regardless of what you specify in entrypoint configuration.