If you create an evaluation queue named "foo" and you have admin access to it at syn123 and then you create anther evaluation queue named "foo" but sent the contentSource to syn234.
The first queue you created will move to this second location. An error should probably be thrown saying this evaluation queue exists.
Any Python version
Can you provide the steps to reproduce this error?
I made an interesting discovery. This only seems to happen when the evaluation queue name is one word:
Creation of first queue
Then storing that same queue
Notice how there is different contentSources. BUT, if I set the evaluation queue name to be greater than one word:
We get the expected error: "An Evaluation already exists with the name 'Echoing me'", which is also accompanied with this "invalid digital signature" linked with the other ticket.
Would it make sense to fix this issue concurrent with the work you’re doing on setting evaluation rounds? (If it doesn’t, that’s fine - but thought I’d check.)
This is not a PLFM bug, but rather a SYNPY bug.
This should be split into SYNPY 2 tickets:
1. Signing the synapse authentication headers does not correctly URL encode the path ()
2. Undesired behavior: when creating an Evaluation with a duplicate name, do not attempt to find the Evaluation's ID based on its name and perform an update. (this ticket )
Here are the results of my debugging:
Quoting 's python output
It mentions During handling of the above exception, another exception occurred: which means that the backend correctly returned a 409, but the client is attempting to handle it. For , is undesired behavior.
The invalid signature error is being throw because evaluation.getByNameURI(evaluation.name) will return '/evaluation/name/Echoing me', but URLs can not have space characters so the requests library will escape space in the URI to '/evaluation/name/Echoing%20me'
BUT the client will be signing '/evaluation/name/Echoing me' via SynapseCredentials.get_signed_headers()
We can see that urllib_parse.urlparse(url).path does not URL encode the space.
So we end up visiting '/evaluation/name/Echoing%20me' but provide a signature for '/evaluation/name/Echoing me', causing the invalid signature error