Skip to content

Reject with indexeddb errors in RemoteConfig.fetch() #2381

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 26, 2019
Merged

Reject with indexeddb errors in RemoteConfig.fetch() #2381

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
66f991e
pass the indexeddb errors to the caller.
Feiyang1 Nov 26, 2019
44f8645
[AUTOMATED]: Prettier Code Styling
Feiyang1 Nov 26, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 32 additions & 35 deletions packages/remote-config/src/remote_config.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -129,41 +129,38 @@ export class RemoteConfig implements RemoteConfigType {
* {@link DEFAULT_FETCH_TIMEOUT_SECONDS}.
*/
async fetch(): Promise<void> {
return new Promise(async (resolve, reject) => {
// Aborts the request after the given timeout, causing the fetch call to
// reject with an AbortError.
//
// <p>Aborting after the request completes is a no-op, so we don't need a
// corresponding clearTimeout.
//
// Locating abort logic here because:
// * it uses a developer setting (timeout)
// * it applies to all retries (like curl's max-time arg)
// * it is consistent with the Fetch API's signal input
const abortSignal = new RemoteConfigAbortSignal();

setTimeout(async () => {
// Note a very low delay, eg < 10ms, can elapse before listeners are initialized.
abortSignal.abort();
}, this.settings.fetchTimeoutMillis);

// Catches *all* errors thrown by client so status can be set consistently.
try {
await this._client.fetch({
cacheMaxAgeMillis: this.settings.minimumFetchIntervalMillis,
signal: abortSignal
});

await this._storageCache.setLastFetchStatus('success');
resolve();
} catch (e) {
const lastFetchStatus = hasErrorCode(e, ErrorCode.FETCH_THROTTLE)
? 'throttle'
: 'failure';
await this._storageCache.setLastFetchStatus(lastFetchStatus);
reject(e);
}
});
// Aborts the request after the given timeout, causing the fetch call to
// reject with an AbortError.
//
// <p>Aborting after the request completes is a no-op, so we don't need a
// corresponding clearTimeout.
//
// Locating abort logic here because:
// * it uses a developer setting (timeout)
// * it applies to all retries (like curl's max-time arg)
// * it is consistent with the Fetch API's signal input
const abortSignal = new RemoteConfigAbortSignal();

setTimeout(async () => {
// Note a very low delay, eg < 10ms, can elapse before listeners are initialized.
abortSignal.abort();
}, this.settings.fetchTimeoutMillis);

// Catches *all* errors thrown by client so status can be set consistently.
try {
await this._client.fetch({
cacheMaxAgeMillis: this.settings.minimumFetchIntervalMillis,
signal: abortSignal
});

await this._storageCache.setLastFetchStatus('success');
} catch (e) {
const lastFetchStatus = hasErrorCode(e, ErrorCode.FETCH_THROTTLE)
? 'throttle'
: 'failure';
await this._storageCache.setLastFetchStatus(lastFetchStatus);
throw e;
}
}

async fetchAndActivate(): Promise<boolean> {
Expand Down