hcengineering/platform · error · PlatformError
result.error
Error message
result.error
What it means
searchFulltext wraps its request with withRetry; even on HTTP 200 the server can embed a Status error in the JSON body. If result.error is defined, the client throws a PlatformError carrying that Status. This is an application-level error reported by the server rather than a transport failure.
Source
Thrown at foundations/core/packages/api-client/src/rest/rest.ts:306
}
if (options.limit != null) {
params.append('limit', `${options.limit}`)
}
const requestUrl = concatLink(this.endpoint, `/api/v1/search-fulltext/${this.workspace}?${params.toString()}`)
const response = await fetch(requestUrl, {
method: 'GET',
headers: this.jsonHeaders(),
keepalive: true
})
if (!response.ok) {
await this.checkRateLimits(response)
throw new PlatformError(unknownError(response.statusText))
}
this.updateRateLimit(response)
return await extractJson<TxResult>(response)
})
if (result.error !== undefined) {
throw new PlatformError(result.error)
}
return result
}
async domainRequest<T>(
domain: OperationDomain,
params: DomainParams,
options?: DomainRequestOptions
): Promise<DomainResult<T>> {
const requestUrl = concatLink(this.endpoint, `/api/v1/request/${domain}/${this.workspace}`)
await this.checkRate()
return await withRetry(async () => {
const response = await fetch(requestUrl, {
method: 'POST',
headers: this.jsonHeaders(),
keepalive: true,
body: JSON.stringify(params)View on GitHub (pinned to 63e28dc964)
Solutions
- Inspect result.error (Status.code/message) in a catch of PlatformError to learn the server-side cause.
- Validate the query/params passed to searchFulltext against the server's expected format.
- Check server logs for the correlating internal error.
- Upgrade client/server to matching versions if the Status indicates an unknown/unsupported operation.
Example fix
// before
const res = await client.searchFulltext(query, {})
// after
try { const res = await client.searchFulltext(query, {}) }
catch (e) { if (e instanceof PlatformError) console.error('server status:', e.message); throw e } Defensive patterns
Strategy: try-catch
Validate before calling
// Validate query shape before sending; malformed input is a common cause of embedded Status errors
if (typeof query !== 'string' || query.length > 512) throw new Error('query must be a reasonable-length string') Type guard
function isPlatformError(e: unknown): e is PlatformError {
return e instanceof PlatformError
} Try / catch
try {
return await client.searchFulltext(query, {})
} catch (e) {
if (isPlatformError(e)) {
// result.error was set by the server: inspect Status message for the app-level cause
console.error('Search failed server-side:', e.message)
}
throw e
} Prevention
- Sanitize and limit query parameters before calling searchFulltext
- Treat PlatformError messages as server Status payloads and route them to your logging/monitoring
- Match client version to server so response shapes stay compatible
When it happens
Trigger: Server processes the search request but responds with { error: Status } — e.g. invalid query parameters, workspace-level processing failure, or internal transactor error surfaced in the response body.
Common situations: Malformed query string rejected by the search engine, workspace data issues, server-side bug during fulltext indexing/lookup, version mismatch between client expectations and server response shape.
Related errors
- unknownError(response.statusText)
- Upload failed:
- Status id is required when creating in static model. Missing
- Status id is required when creating in static model. Missing
- ${reply.error}
AI-assisted analysis of hcengineering/platform@63e28dc964 (2026-08-29).
Data as JSON: /api/errors/22e557acae59849d.
Report an issue: GitHub.