hcengineering/platform · info

measure slow findAll

Error message

measure slow findAll

What it means

The client-resources connection's findAll sends a 'findAll' request and measures round-trip time via the measure callback. If the total time exceeds 1000ms or the server-side execution time exceeds 500ms (browser only), it warns 'measure slow findAll' with a timing breakdown (time, serverTime, toReceive, queue) and the queried _class. It is a performance diagnostic, not an error - the query still succeeds.

Source

Thrown at plugins/client-resources/src/connection.ts:780

  getAccount (): Promise<Account> {
    if (this.account !== undefined) {
      return Promise.resolve(clone(this.account))
    }
    return this.sendRequest({ method: 'getAccount', params: [] })
  }

  async findAll<T extends Doc>(
    _class: Ref<Class<T>>,
    query: DocumentQuery<T>,
    options?: FindOptions<T>
  ): Promise<FindResult<T>> {
    const result = await this.sendRequest({
      method: 'findAll',
      params: [_class, query, options],
      measure: (time, result, serverTime, queue, toReceive) => {
        if (typeof window !== 'undefined' && (time > 1000 || serverTime > 500)) {
          console.warn(
            'measure slow findAll',
            time,
            serverTime,
            toReceive,
            queue,
            _class,
            query,
            options,
            result,
            JSON.stringify(result).length
          )
        }
      }
    })
    if (result.lookupMap !== undefined) {
      // We need to extract lookup map to document lookups
      for (const d of result) {
        if (d.$lookup !== undefined) {

View on GitHub (pinned to 63e28dc964)

Solutions

  1. Pass query options (limit, sort) to findAll to bound result size for large classes.
  2. Add/optimize database indexes for the queried _class and its filter fields.
  3. Check serverTime vs time in the warning: high serverTime means fix the query/index; high total time only means investigate network/queue latency.
  4. Profile the calling code - batch or cache repeated heavy findAll calls.

Example fix

// before
const result = await client.findAll(task.class.Task, { done: false })
// after
const result = await client.findAll(task.class.Task, { done: false }, { limit: 100, sort: { modifiedOn: -1 } }) // bounded, indexed query
Defensive patterns

Strategy: fallback

Validate before calling

// Bound the query before issuing findAll
const options = { limit: 100, sort: { modifiedOn: SortingOrder.Descending } }
await client.findAll(task.class.Task, query, options)

Prevention

When it happens

Trigger: Any findAll call through this connection where (time > 1000 || serverTime > 500) in a browser context: slow query execution server-side, large result sets, or long client-side queueing/network latency.

Common situations: Queries on large classes without limiting options (no limit/projection); missing DB indexes; cold caches after deployment; chatty client code issuing heavy findAll on UI load; slow network links inflating total time.

Related errors


AI-assisted analysis of hcengineering/platform@63e28dc964 (2026-08-29). Data as JSON: /api/errors/ed6e8d9ab804b09e. Report an issue: GitHub.