Closed dkasak closed 1 week ago
One remaining questionable thing is that due to the previous change in default, some code which used to return
M.BAD_JSON
now returnsM.INVALID_PARAM
instead, due to the validation being done withinparse_integer
instead of directly in the caller. One such example is the aforementioned C2S/hierarchy
endpoint. Is this a problem? The spec doesn't mention which error code should be returned in this case and there were obviously no checks for this. Is there a general principle on whetherM.BAD_JSON
orM.INVALID_PARAM
should be returned on a disallowed (but well formed) value within a JSON body?
None of these are JSON are they? They all look like query parameters?
Uhh, you're right. The previous error code was wrong then, which caused my thinko. Even better, then this fixes the error codes too.
During https://github.com/element-hq/synapse/pull/16920, we seem to have inadvertently disallowed negative integers in
parse_integer
by default. This was contrary to theparse_integer
documentation.Surprisingly, nothing really broke, which indicates that things mostly do expect positive integers. Running an ast-grep query confirms it:
As can be seen, these boil down to timestamps, limits, timeouts, sizes, etc, none of which really make sense to be negative. So it seems we've inadvertently stumbled into
This PR:
/hierarchy
handlerBrings the default of
parse_integer_from_args
into alignment, by defaulting to disallowing negatives. This is a behaviour change, but that function is only directly called with the default in federation handlers for the following endpoints/params:limit
for https://spec.matrix.org/v1.10/server-server-api/#get_matrixfederationv1publicroomslimits
for https://spec.matrix.org/v1.10/server-server-api/#get_matrixfederationv1backfillroomidts
for https://spec.matrix.org/v1.10/server-server-api/#get_matrixfederationv1timestamp_to_eventroomidAll of these are meant to be non-negative.
One remaining questionable thing is that due to the previous change in default, some code which used to return
M.BAD_JSON
now returnsM.INVALID_PARAM
instead, due to the validation being done withinparse_integer
instead of directly in the caller. One such example is the aforementioned C2S/hierarchy
endpoint. Is this a problem? The spec doesn't mention which error code should be returned in this case and there were obviously no checks for this. Is there a general principle on whetherM.BAD_JSON
orM.INVALID_PARAM
should be returned on a disallowed (but well formed) value within a JSON body?Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.