This bug occurred due to a combination of two edge cases:

1. The Python Prometheus client does allow `None` as a label value, except when implementing a custom collector[1] which we are doing in this case. If you try to use `None` as a label value when implementing a custom collector, everything will work fine just until the metrics are actually exposed (for example when Prometheus sends a request to the `/metrics` endpoint) which will raise an unhandled exception.

2. In Aleph, every collection can be assigned zero or more countries and languages. These are stored as array columns in Postgres. For example, if a collection contains data about Germany and Luxembourg, that would be stored as `{de,lu}`. However, in real-life, we also have a few collections with `{NULL}` (instead of just an empty array `{}`). The same is the case for languages. That means we were trying to expose a Prometheus metrics such as `aleph_collection_countries{country=None}` which fails due to 1). I’m not entirely sure why this happens, but this seems to affect only collections that have been created quite some time ago, so it might be due to a bug in a previous version of Aleph.

I’ve adjusted the test cases to ensure that we try to expose the collected metrics in the Prometheus plaintext format (in the same way it would be done in production when requesting the `/metrics` endpoint) and fixed the metrics collector to ignore `NULL` values in the `countries` and `languages` columns.

[1]: prometheus/client_python#270