API documentation for subject field in decision endpoint still states that it's deprecated. Without the field you would need to make multiple requests to the endpoint.

The easiest way now is to allow asking for decision on multiple subjects. There is probably better and more consistent way to do this. So let me hear your ideas.

(I'll have to update the documentation.)

CC @bowlofeggs @sbaird

oh, _decision_subject and _decision_subjects is quite confusing... Can we rename them to distinguish them a little bit better?

Why are you removing this part?

Why not? :D We've put it here since we didn't want to raise an error if someone doesn't want to use the RemoteRule feature. We can maybe put a check in the RemoteRule class...

This block is completely unrelated to this function (which should just serve decisions). The code seems to check whether the application is configured correctly on every decision request. It could done after loading policies and configuration.

BTW, the code is very awkward :) -- I would expect something like:

if ('DIST_GIT_BASE_URL' not in current_app.config or
    'DIST_GIT_URL_TEMPLATE' not in current_app.config or
    'KOJI_BASE_URL' not in current_app.config or 
        any(isinstance(rule, RemoteRule) for ...):
    raise InternalServerError(...)

As I mentioned in comment above, 'subject' (deprecated field since v0.8) is still needed if we want do make decision about multiple bodhi builds in one request.

This block is completely unrelated to this function (which should just serve decisions). The code seems to check whether the application is configured correctly on every decision request. It could done after loading policies and configuration.
BTW, the code is very awkward :) -- I would expect something like:
if ('DIST_GIT_BASE_URL' not in current_app.config or
'DIST_GIT_URL_TEMPLATE' not in current_app.config or
'KOJI_BASE_URL' not in current_app.config or
any(isinstance(rule, RemoteRule) for ...):
raise InternalServerError(...)

so great that you changed it

+1 for me