Unfortunately, at the moment those calls are necessary. Features are paged but the feature states (i.e. the enabled states/remote config for the environment) are accessed separately, so the frontend currently needs all feature states to be accessible in order to match them up.

To get to 76 pages of 200 is a very extreme case but this probably needs to be sorted.

I think the only way to solve this is to start returning the feature state in the /features call, we pass the environment as a get param to this endpoint, so I think it's possible @matthewelwell ? The only alternative is to do a get per result which seems excessive.

@kyle-ssg , I think we can add this to the payload in the case that the environment query parameter is provided.

@matthewelwell Great, could this get added / assigned to me when ready?

I must say urgency of this task is not too high because there I wasn't able to reproduce this. I believe my local setup had a bug and imported the same flag many times. Certainly 76 * 200 = 15,000 feature flags is a lot to handle but must say not impossible 🙂

@kyle-ssg the response to the /projects/:id/features/ endpoint now returns an attribute of environment_feature_state which includes the default environment feature state when the environment query parameter is provided.