[FR] Custom default RetryConfig

[regnaio]

Is your feature request related to a problem? Please describe.
Please allow users of firebase-admin-node to define their own default RetryConfig

Currently, users are forced to use the default RetryConfig:

export function defaultRetryConfig(): RetryConfig {
  return {
    maxRetries: 4,
    statusCodes: [503],
    ioErrorCodes: ['ECONNRESET', 'ETIMEDOUT'],
    backOffFactor: 0.5,
    maxDelayInMillis: 60 * 1000,
  };
}

Personal use case: I have a Node app where I want zero retries for Firebase HTTP requests. Retries create setTimeout timers that can cause I/O polling blocking of setImmediate according to the Event Loop. Thus, retries are causing hitches (ranging from hundreds of milliseconds to a few seconds) in my otherwise tight setImmediate loop, which I want to run as interrupted as possible

---

Describe the solution you'd like
Please somehow allow users to define their own RetryConfig, perhaps as a parameter when initalizing Firebase Admin:

import * as admin from 'firebase-admin';

const app = admin.initializeApp(
  options?: admin.AppOptions | undefined, // perhaps include custom RetryConfig as a field in options?
  // ...
)

---

Describe alternatives you've considered

1. Wrapping firebase-admin-node in a Worker and using Comlink to successfully prevent I/O polling blocking, but I'd rather avoid using Worker
2. Rewriting a barebones Node Firebase Admin with only the API endpoints I need, but I'd much rather use the official firebase-admin-node

---

Additional context

• Internal API for retrying HTTP requests #518
• Automatically retrying on 503 errors #556

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[markusn]

@lahirumaramba any updates on this? It is a much needed feature.

[dtsvn-minhnh]

@lahirumaramba
I would like to retry when statusCodes includes 500 or 503.
Is there any way to achieve that with current implementation or do we need to resolve @regnaio 's problem first?

[treyshedrick]

Related #43 (comment)

Would be nice to have this.

[milcho0604]

+1 with a concrete production use case.

Default retry semantics for FCM — 15s per-attempt timeout × up to 4 retries with backoff — put the structural worst case for a single call far above what a push relay can budget (we measured calls hitting exactly 30s = 15s × 2 attempts in the common case). We needed (a) a lower per-attempt timeout and (b) visibility into whether retries fired at all — and ended up runtime-patching the request layer for both, which is version-fragile.

A public way to pass a RetryConfig (attempts, per-attempt timeout, backoff, retriable codes) at app/messaging init would have covered it. Filed the observability half separately with wire-level measurements: #3214.