When you chain `.then()` or `await` a Promise, you react to outcomes—but you can't ask a Promise "what's your current state?" This gap in the API creates real friction when debugging complex asynchronous flows or building monitoring logic.
A clever workaround uses `Promise.race()` to probe state indirectly.
Why Native Promise State Is Hidden
JavaScript Promises operate in three phases: waiting (pending), success (fulfilled), or failure (rejected). Once settled, they lock in—and the standard API never exposes which state you hit, only what happens next.
This works fine for simple flows. But imagine monitoring a queue of background requests, or building retry logic that depends on whether a prior call succeeded. Without state inspection, you either duplicate logic or restructure your code around events rather than status.
The language spec intentionally hides this, encouraging developers to use callbacks rather than polling. That philosophy fits most use cases, yet leaves gaps for tooling and advanced patterns.
The Race Technique Explained
The solution exploits a specific behavior: when two promises race, the first to settle wins. If we pair any Promise with an instantly-resolving counterpart, the winner reveals the unknown Promise's state.
The instant resolver looks like this:
“`javascript
Function instant(value) {
Return new Promise(resolve => resolve(value));
}
“`
Unlike `setTimeout(fn, 0)`, this doesn't defer execution—it resolves synchronously on the next microtask queue tick. This distinction matters for correctness.
Now we build three inspectors:
“`javascript
Async function checkFulfilled(p) {
Const fallback = instant(false);
Const probe = p.then(() => true).catch(() => false);
Return Promise.race([fallback, probe]);
}
Async function checkRejected(p) {
Const fallback = instant(false);
Const probe = p.then(() => false).catch(() => true);
Return Promise.race([fallback, probe]);
}
Async function checkSettled(p) {
Const fallback = instant(false);
Const probe = p.then(() => true).catch(() => true);
Return Promise.race([fallback, probe]);
}
“`
Each function races a `false` against a derived promise that converts outcomes to booleans. If the original Promise resolves, the derived promise wins. If it rejects, the catch branch wins. Either way, you get a boolean without altering the original.
Hands-On Example
Say your app fires multiple API calls during startup and you want to log which ones succeeded. You could wrap each call with try/catch, but that scatters your error handling.
Instead, register each Promise with a tracker:
“`javascript
Const trackers = [];
Function track(promise, label) {
Trackers.push({ label, promise });
Return promise;
}
// Later, inspect all at once
For (const { label, promise } of trackers) {
If (await checkRejected(promise)) {
Console.warn(`${label} failed`);
}
}
“`
This separates tracking logic from business logic—a pattern that shines in debugging dashboards or integration test harnesses.
Why This Matters for Android Web Developers
If you build web apps that run in Android Chrome or WebViews, you encounter Promises constantly. Hybrid apps using frameworks like Capacitor or Cordova rely on asynchronous bridges between JavaScript and native layers. Understanding Promise state helps you write more predictable request-and-response handling.
For pure web developers, this technique becomes useful when instrumenting fetch calls, IndexedDB transactions, or Background Sync API workflows—common patterns in Progressive Web Apps targeting Android devices.
Our Analysis
The approach trades simplicity for capability. Most developers never need to inspect Promise state because reactive patterns handle outcomes naturally. But for logging, monitoring, or complex orchestration, these helpers fill a genuine gap.
The zero-delay pattern is elegant because it introduces no artificial latency. The microtask queue handles resolution fast enough for state detection without side effects.
One caveat: these functions return new Promises, so they're asynchronous themselves. You can't use them in synchronous contexts without blocking or additional unwrapping.
Watch for potential native solutions. TC39 proposals occasionally revisit Promise introspection, though no concrete spec exists yet. If adopted, these helpers would become transitional utilities rather than permanent fixtures.
Bottom Line
You can reliably detect Promise state today using `Promise.race()` with instant-resolving fallbacks. The pattern works across all modern browsers and Android WebViews. For debugging async flows or building monitoring tools, it's a practical addition to your toolkit.
Key takeaways
- `Promise.race()` with instant fallbacks probes state without side effects
- Derived Promises convert outcomes to booleans for detection
- State inspection enables cleaner monitoring and debugging logic
- The pattern works everywhere Promises run, including Android WebViews
Frequently asked questions
Do these helpers alter the original Promise?
No. They create separate Promises for inspection while leaving the original untouched.
Can I call these without async/await?
You can, but you'd need to chain `.then()` on the returned Promise. Async syntax makes the flow much clearer.
What if the Promise never settles?
These helpers won't help there—they only detect settled Promises. For timeout scenarios, pair them with `Promise.race()` against a deliberate delay.
Do these work in older browsers?
They require modern Promise support, so they run in Android Chrome, Firefox, and Safari. Legacy environments need polyfills.
Is there a simpler way to get Promise state?
Not natively in JavaScript today. The race technique remains the cleanest workaround without modifying Promise prototypes.