In relatively rare situations and through no fault of ours (like network issues) the fetch call here can throw an error. (One way to repro: turn throttling to Offline in Firefox and submit a form.)
|
public async request<Data>({ |
|
body, |
|
path, |
|
query, |
|
host, |
|
...fetchParams |
|
}: FullParams): Promise<ApiResult<Data>> { |
|
const url = (host || this.host) + path + toQueryString(query); |
|
const init = { |
|
...mergeParams(this.baseParams, fetchParams), |
|
body: JSON.stringify(snakeify(body), replacer), |
|
}; |
|
return handleResponse(await fetch(url, init)); |
|
} |
|
} |
That means an error of arbitrary shape gets thrown up to the web console, which doesn't know what to do with it, and in fact is not aware that this can happen. In practice, this has been ok because we primarly rely on a message property on our ApiError type which is also present on regular Errors. But it would be nice to be able to explicitly handle non-API errors that occur while making an API call. See oxidecomputer/console#2569.
In relatively rare situations and through no fault of ours (like network issues) the
fetchcall here can throw an error. (One way to repro: turn throttling toOfflinein Firefox and submit a form.)oxide.ts/oxide-api/src/http-client.ts
Lines 146 to 160 in 7890e4d
That means an error of arbitrary shape gets thrown up to the web console, which doesn't know what to do with it, and in fact is not aware that this can happen. In practice, this has been ok because we primarly rely on a
messageproperty on ourApiErrortype which is also present on regularErrors. But it would be nice to be able to explicitly handle non-API errors that occur while making an API call. See oxidecomputer/console#2569.