Fix failure of calling authenticated APIs from secondary AsgardeoProvider Instances (Multi-Provider Support)

[kavindadimuthu]

Purpose

This pull request introduces multi-HTTP clients support when multiple provider instances are implemented. This ensures that all authenticated HTTP operations are isolated per instance.

The most important changes are:

Instance-specific HTTP Client Management

• Refactored HttpClient to support multiple isolated HTTP client/axios instances, each keyed by instance ID, preventing state conflicts between auth contexts. All HTTP handler flags and callbacks are now instance-specific. [1] [2] [3] [4] [5] [6] [7] [8]
• Updated all usages of HttpClient.getInstance() to provide the correct instance ID, ensuring HTTP requests are routed through the correct context. [1] [2] [3] [4]

Related Issues

• Fixes bug: Authenticated API Calls Fail for Secondary AsgardeoProvider Instances (Multi-Provider Support) #335

Related PRs

• Add support for multiple Asgardeo Provider instances via optional instanceID #325
• Fix isolation of login flows when Using Multiple AuthProvider Instances #327
• Fix failure of calling authenticated APIs when multiple AsgardeoProvider instances are used #334

Checklist

• Followed the CONTRIBUTING guidelines.
• Manual test round performed and verified.
• Documentation provided. (Add links if there are any)
• Unit tests provided. (Add links if there are any)

Security checks

• Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines?
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets?

[DonOmalVindula]

The multiton refactoring looks good overall and the approach is correct. However, there's a this-binding bug that needs to be fixed before merging — see inline comments.

[asgardeo-github-bot]

🦋 Changeset detected

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

[DonOmalVindula]

A few more issues I noticed during review.

[DonOmalVindula]

Bug: worker-core.ts has the same pattern at the same line — HttpClient.getInstance() without an instanceId — but was missed in this PR. The web worker path will always fall back to instanceId=0 regardless of which provider spawned it.

Suggestion: Thread the instanceID through to WebWorkerCore the same way it's done in MainThreadClient:

export const WebWorkerCore = async (
  instanceID: number,
  config: AuthClientConfig<WebWorkerClientConfig>,
  ...
): Promise<WebWorkerCoreInterface> => {
  ...
  const _httpClient: HttpClientInstance = HttpClient.getInstance(instanceID);
  ...
};

See packages/browser/src/__legacy__/worker/worker-core.ts:65.

[DonOmalVindula]

Memory leak: Instances are added to these static Maps but never removed. If an AsgardeoProvider unmounts and remounts (e.g. React hot-reload, dynamic multi-tenant switching), stale axios instances with outdated interceptors and callbacks will accumulate.

Suggestion: Add a static cleanup method:

public static destroyInstance(instanceId: number): void {
  const axiosInstance = this.instances.get(instanceId);
  if (axiosInstance) {
    // Eject interceptors to prevent memory leaks
    axiosInstance.interceptors.request.clear();
    axiosInstance.interceptors.response.clear();
  }
  this.instances.delete(instanceId);
  this.clientInstances.delete(instanceId);
}

This should be called during provider teardown.

[DonOmalVindula]

Dead code: clientInstances is write-only — nothing ever calls clientInstances.get(). If you add a destroyInstance() method (see my other comment), this map becomes useful for cleanup. Otherwise, it should be removed to avoid confusion.