Status list cannot be disabled

[berkes]

When setting the env var IS_STATUS_LIST_ENABLED to false, I would expect the status list API not to be present nor instantiated.

However, the agent also checks if (STATUS_LIST_API_FEATURES.length > 0) { which we cannot set to nothing:

export const STATUS_LIST_API_FEATURES: statusListFeatures[] = env('STATUS_LIST_API_FEATURES', ENV_VAR_PREFIX)
  ? (env('STATUS_LIST_API_FEATURES', ENV_VAR_PREFIX)?.split(',') as statusListFeatures[])
  : ['status-list-hosting', 'w3c-vc-api-credential-status']

We we make it false, empty, null, the defaults are used and we still get a status list API as can be witnessed by a line:

Status List API enabled, with features: ["status-list-hosting","w3c-vc-api-credential-status"]

Setting STATUS_LIST_API_FEATURES to ,, " " or another truthy value results in strange behaviour as we'll then enable them with features like "", "" (two empty strings) for example.
Setting it to anything falsey enables the default values.

I would personally prefer predictable and simple behaviour: no defaults hidden away in code, but rather explicitly set in the .env.example or documentation. That not only simplifies the config loaders, it makes behaviour and detection of misconfiguration and requirements far more predictable.

E.g. if upstream code must depend on it being a list, at least the following would make it more predictable and simpler:

export const STATUS_LIST_API_FEATURES: statusListFeatures[] = env('STATUS_LIST_API_FEATURES', ENV_VAR_PREFIX)
  ? (env('STATUS_LIST_API_FEATURES', ENV_VAR_PREFIX)?.split(',') as statusListFeatures[]) : []

But actually, even simpler and more predictable:

export const STATUS_LIST_API_FEATURES: statusListFeatures[] = (env('STATUS_LIST_API_FEATURES', ENV_VAR_PREFIX)!.split(',');

This, IMHO, applies to many of the configuration of both the large list of ENV vars mixed with conf files, as it often is a long treasure-hunt of backtracing to find why/where/when some ENV var or config var is passed along, overridden, fall-backed or even ignored. This "why is the status list still being switched on" was such a hunt :)

[berkes]

I've now "fixed" it by adding extra logic:

if (IS_STATUS_LIST_ENABLED && STATUS_LIST_API_FEATURES.length > 0) {

But would personally prefer to fix it by removing logic :)