Does the RPC mechanism process server commands in non-200 (e.g. 401) HTTP responses?

[mikepryme]

Question

The SDK's RPC mechanism allows the server to return commands via background_geolocation in the response body. For example:

{
  "background_geolocation": ["stop"]
}

Does the SDK parse the response body for RPC commands when the HTTP status is non-200 (specifically 401)?

We're trying to determine if we can include RPC commands in a 401 Unauthorized response body to stop the plugin when authentication is permanently broken.

Background / Use Case

We use JWT authentication with Cognito and a custom authorization.refreshUrl for token refresh. In some cases, a device's refresh token becomes permanently invalid (e.g., revoked server-side, Cognito pool migration). When this happens while the app is backgrounded, the following loop occurs:

1. Plugin uploads locations → server returns 401
2. Plugin auto-refreshes token via refreshUrl → token-proxy returns 400 (invalid refresh token)
3. Plugin has no valid token
4. Next heartbeat/location trigger → plugin uploads again → 401
5. Repeat forever

Since the JavaScript onHttp and onAuthorization listeners don't fire while the app is backgrounded (WebView is suspended), the only way to break this loop from the server side would be via the RPC mechanism.

What We'd Like to Do

Return an RPC stop command in the 401 response body after detecting repeated auth failures from the same device:

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
  "error": "Unauthorized",
  "background_geolocation": ["stop"]
}

If the SDK doesn't process responseText for RPC on 401 responses, we'd need to return a 200 with the RPC command instead, which breaks standard HTTP semantics.

Specific Questions

1. Does the SDK parse the response body for background_geolocation RPC commands on all HTTP responses, or only on successful (200/201/204) responses?
2. If not currently supported on 401, would you consider it as a feature request?
3. Is there any other recommended approach to break an infinite 401 retry loop from the server side when the app is backgrounded?

Thank you!

[github-actions]

This issue is stale because it has been open for 30 days with no activity.