[bug] PipelinesController#index N+1 — kanban fetch takes 8-13s, blocks UI save

[dvlexp]

Summary

GET /api/v1/pipelines fires ~6 SQL queries per pipeline item (tasks_info + services_info + others). With ~1000 items → ~6000 queries → 8-13s response → Nginx/Traefik times out → kanban UI gets "pending" state and never updates after edits.

Repro

1. Seed DB with pipeline + ~500 pipeline_items
2. curl -H "api_access_token: X" /api/v1/pipelines
3. Observe duration 8s+ and Rails log showing per-item SQL queries

Root cause

app/controllers/api/v1/pipelines_controller.rb includes 6 tasks_info / services_info method calls inside an iteration over pipeline_items, each triggering its own queries.

Suggested fix

Move task/service counts to eager-loaded aggregation:

# before (per item)
@pipelines.each { |p| p.pipeline_items.each { |i| i.tasks_info } }

# after (bulk aggregation)
task_counts = Task.where(pipeline_item_id: item_ids).group(:pipeline_item_id, :status).count
service_counts = Service.where(pipeline_item_id: item_ids).group(:pipeline_item_id, :status).count

Or use includes(:tasks, :services) if serializer can tolerate loaded associations.

Impact

• Kanban fetch 8-13s → 60-180ms (tested in our fork)
• Unblocks edit save (UI was timing out and rolling back locally)

Our workaround

Rails initializer overrides the index method with bulk aggregation. See RXP patch #4 in rxp_patches.rb (happy to PR if helpful).

Identified in image evoapicloud/evo-ai-crm-community:latest dated 2026-04-25.