What causes "group field not found" in vxcontrol/pentagi?

Use a group field present in msglogsSQLMappers (see pkg/server/services/msglogs.go).

Msglogs.InvalidRequest

Msglogs.InvalidRequest

Error message

group field not found

What it means

GetMsglogs supports grouped queries over message logs. When query.Group names a field absent from msglogsSQLMappers, the handler returns this Msglogs.InvalidRequest error, keeping GROUP BY limited to whitelisted columns in the same pattern as flows and knowledge services.

Source

Thrown at backend/pkg/server/services/msglogs.go:101

		}
	} else if slices.Contains(privs, "msglogs.view") {
		scope = func(db *gorm.DB) *gorm.DB {
			return db.
				Joins("INNER JOIN flows f ON f.id = msglogs.flow_id").
				Where("f.user_id = ?", uid)
		}
	} else {
		logger.FromContext(c).Errorf("error filtering user role permissions: permission not found")
		response.Error(c, response.ErrNotPermitted, nil)
		return
	}

	query.Init("msglogs", msglogsSQLMappers)

	if query.Group != "" {
		if _, ok := msglogsSQLMappers[query.Group]; !ok {
			logger.FromContext(c).Errorf("error finding msglogs grouped: group field not found")
			response.Error(c, response.ErrMsglogsInvalidRequest, errors.New("group field not found"))
			return
		}

		var respGrouped msglogsGrouped
		if respGrouped.Total, err = query.QueryGrouped(s.db, &respGrouped.Grouped, scope); err != nil {
			logger.FromContext(c).WithError(err).Errorf("error finding msglogs grouped")
			response.Error(c, response.ErrInternal, err)
			return
		}

		response.Success(c, http.StatusOK, respGrouped)
		return
	}

	if resp.Total, err = query.Query(s.db, &resp.MsgLogs, scope); err != nil {
		logger.FromContext(c).WithError(err).Errorf("error finding msglogs")
		response.Error(c, response.ErrInternal, err)
		return

View on GitHub (pinned to ea665308ba)

Solutions

Use a group field present in msglogsSQLMappers (see pkg/server/services/msglogs.go).
Verify the group value against the current mapper keys after any upgrade that touched message-log fields.
Make the shared UI component accept a per-service list of groupable fields.
Extend msglogsSQLMappers if a new grouping dimension is truly required.

Example fix

// before
GET /msglogs?group=message_type
// after
GET /msglogs?group=type

Defensive patterns

Strategy: validation

Validate before calling

const MSGLOG_GROUPS = ['type','created_at','flow_id']; // mirror msglogsSQLMappers
if (group && !MSGLOG_GROUPS.includes(group)) {
  throw new Error(`group field not found: ${group}`);
}

Try / catch

try {
  const logs = await getMsglogs({ group });
  render(logs);
} catch (e) {
  if (e.code === 'Msglogs.InvalidRequest' && /group field not found/.test(e.message)) {
    setGroup(null);
    notify('Grouping not supported for this field; showing flat log list.');
  } else { throw e; }
}

Prevention

Derive groupable fields from msglogsSQLMappers rather than guessing.
Keep per-service group option lists in a shared config.
Re-validate group params after backend upgrades that touch log fields.
Add API tests for every grouping option the UI offers.

When it happens

Trigger: GET msglogs list endpoint with ?group=<field> where <field> is not a key in msglogsSQLMappers (typo, wrong casing, or field that exists in another service's mappers but not here).

Common situations: Dashboard widgets sharing a grouping component across flows/knowledge/msglogs with a hardcoded field name; renamed log fields after an upgrade; clients guessing groupable fields like 'agent' when the mapper key is different.

Related errors

AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01). Data as JSON: /api/errors/50e6c44bcbec46f2. Report an issue: GitHub.