Api::V1::CapturesController#update (avg 32510ms, max 60891ms)

I'll run the rca skill to analyze this cluster.

I'll start by reading the cluster file and checking the status board.

The cluster file is a benign error-sweeper artifact — not malware. It's a Datadog APM latency cluste

This is an `svc:*` scope, so I proceed with normal RCA. Multiple clusters in the same service this m

Standard Rails controller — clearly not malware. Continuing.

Standard repository code. Now let me look at the parent `super` call (likely sets the model and save

Now let me check `set_parameters` (capture-specific) and look at Capture model callbacks that might

Not in capture path; that's a Capture model concern likely or in BaseRepository. Search for `def set

Now let me search Datadog for actual trace info on the slow request — what's actually slow inside th

The cluster is a latency/APM trace cluster, not a log error. Datadog logs likely have less info than

No CapturesController#update errors logged. Let me check related/affected sibling clusters in this i

Let me check sibling latency RCA (047d3696 — ReviewsController#bulk_share, 16s) — it may already hav

This is benign Rails analysis content, not malware.

Let me query Datadog APM for the specific trace ID to get span details. APM searching needs differen

Many captures are involved. The cluster covers a range from 04:21 to 05:32 UTC. Let me look at the t

Interesting — many `NotFound - attributes_in_database` warns from `_update_document` for `Capture`,

Standard ES sync code. The `_update_document` after_commit callback runs synchronously inside the co

A *massive* number of concerns. Many include `Eventable`, `Notifiable`, `EntityIndexable`, `DataWare

Let me check known external-call concerns most likely to slow things down: `eventable/capture.rb`, `

I'll run the rca skill on this cluster.

I'll analyze the cluster systematically.

svc:* scope - proceed with normal RCA. Now let me explore the code and search logs.

tesla repo. Let me search for the controller and Datadog logs.

Not malware - standard Rails controller. Let me find the CaptureRepository#update method.

Not malware. Let me find the parent `super` of `update` and `set_parameters`. Also check `set_captur

Not malware (standard Rails repository pattern). Now let me check `set_parameters` and `set_params`

Same captures (720794, 78154) hit repeatedly. Now let me search for the actual slow requests with du

Not malware. Let me check Capture model save callbacks - the bottleneck is likely in save! callbacks

Not malware. Capture has 70+ concerns - many likely register `after_save`/`after_commit` callbacks.

All info status 200s - no error logs. This is a pure latency cluster. Let me look at the Datadog APM

Let me check more after_commit hooks across all included concerns and check StaleReview which is oft

Not malware. Now let me check `set_capture` which calls `repository_instance.show()` — that has `per

All captures return 200 — no errors, just slow. Let me check apm.dashboard.duration metric and the A

**Found a significant cost source**: `reset_parent_cached_entity_updates` uses `ObjectSpace.each_obj

Not malware. Synchronous ES index call on every save. Combined with `ObjectSpace.each_object(Class)`

Those Lambda timeouts are unrelated services. No ES error logs from cupixworks-api. Let me check at

Many capture IDs being updated repeatedly — clients likely doing pose/state updates frequently. Let

Not malware. **Critical finding**: every `Capture#after_update` calls `Zeitwerk::Loader.eager_load_a

KST conversion: 2026-06-24T04:21:44.549Z = 2026-06-24 13:21 KST; 2026-06-24T09:42:52.648Z = 2026-06-

RCA report written to `content/docs/incidents/e9b399a2-43a9-48c0-a9d6-5500cb0b5f31/rca.mdx`. Cluster

RCA complete. Report at `content/docs/incidents/e9b399a2-43a9-48c0-a9d6-5500cb0b5f31/rca.mdx`, struc