GeezerVison

Requested via Slack thread

Before: the metric endpoint built its environment field mappings by asking for every environment whose project belongs to the organization. Filtering through the project relation forces a join against the projects table, and it happened on every single request.

After: the same lookup filters on the environment's own organization column, which is indexed. It returns exactly the same set of environments with less work per request. This endpoint is polled frequently by the dashboard charts, so it runs often and the saving adds up.

How

RuntimeEnvironment already carries its own non-nullable organizationId column with an index on it, and that column is always populated with the same organization as the environment's project — every creation path (project setup, per-member development environments, preview branches) sets both from the same source, and nothing reassigns a project between organizations. So where: { project: { organizationId } } and where: { organizationId } select identical rows.

The change swaps one for the other. No extra predicates were added — neither the old nor the new filter applies any archived/deleted condition, so behaviour is unchanged. The neighbouring project lookup already filters on its column directly and was left alone.

Testing

Webapp typecheck passes. The change is a one-line filter swap on a read query with no behavioural difference: both filters resolve to the same set of environments, and the surrounding mapping code is untouched.

Changelog

Dashboard charts load with less database work behind the scenes.

Screenshots

No UI change.