wp.data.select( store ).getEntityRecords seems to be hiding all errors. Is this a bug?

[chrono-meter]

I noticed that when using getEntityRecords, queries that would normally result in server errors no longer produce errors.
Upon reviewing the source code, it appears to completely ignore the errors.
getEntityRecord function is trapped in finally.
Is this a bug?

[daveshenal]

Not really a bug in the sense of "broken code," it's an intentional (if incomplete) workaround, and the WordPress team has openly flagged it as a known limitation right in the source comments.

The getEntityRecord resolver (singular) has had this exact pattern for years:

} catch ( error ) {
    // We need a way to handle and access REST API errors in state
    // Until then, catching the error ensures the resolver is marked as resolved.
} finally {
    dispatch.__unstableReleaseStoreLock( lock );
}

getEntityRecords (plural, what you're using) didn't originally have this catch at all, which actually caused a worse problem: if the REST call failed, the resolver would throw, and isResolving() / hasFinishedResolution() would get stuck forever thinking the selector never finished. That left UI components in permanent limbo, not even "errored," just stuck on "loading." This was fixed in PR #36353, which updated getEntityRecords to mirror getEntityRecord's approach by introducing a catch statement specifically so the resolver would always reach a "resolved" state, success or failure.

So the empty catch block isn't an oversight, it's there on purpose to guarantee resolution completes. The tradeoff is exactly what you noticed: the error itself goes nowhere. It isn't stored, it isn't rethrown, it's just discarded after letting the resolver finish.

A relevant detail: core data does have error tracking selectors for writes, getLastEntitySaveError and getLastEntityDeleteError, but there's no equivalent fetch error selector for reads via getEntityRecords/getEntityRecord. That gap is what the "Until then" in the code comment is referring to, it was never built.

So to directly answer your question... this looks like a known, acknowledged tradeoff rather than an accidental bug, based on the resolver source and the PR that introduced this behavior (packages/core-data/src/resolvers.js on trunk has the current implementation if you want to confirm against the latest code). If you want to actually see the error, you'd currently need to bypass the resolver and call apiFetch yourself, or wrap the relevant REST endpoint call directly, since the public selector won't surface it. Worth searching open issues for "core data error handling" before filing a new one, since this gap (no read error selector) has come up before and may already have a tracking issue you can add your use case to.

[chrono-meter]

Thank you for the detailed explanation.

I understand the situation, but from the perspective of a user of the library, it's not ideal behavior, so I personally find it hard to accept.