You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
cannot handle error from useFirestoreCollectionData #540
I have a similar issue with useFirestoreDocData and useFirestoreDocDataOnce.
The error actually originates from the SuspenseSubject class which throws an error when the value property is read while the Subject has an error i.e. Firebase Permission Error.
This error is also cannot be caught without a React Error Boundary. I think it would be better to pass in a flag like throwErrorInObservable that allows it to return the initialValue or just undefined to represent the error state. Would be more convenient to check for errors synchronously using the error attribute in the ObservableStatus. I would not mind making a PR for this if maintainers can sign off on it.
// TODO figure out how to reset the cache here, if I _reset() here before throwing
// it doesn't seem to work.
// As it is now, this will burn the cache entry until the timeout fires.
if(this._error){
throwthis._error;
}elseif(!this.hasValue){
throwError('Can only get value if SuspenseSubject has a value');
}
returnthis._valueasT;
}
Another approach could be to not set hasValue as true when there is an error however it seems that there might be a lot of code already dependent on such behaviour.
Bumping this as well. Crashing on FirebaseError: Missing or insufficient permissions renders this library unusable for me as this is a valid use case which I am unable to handle.
Bump. I can't use this library either because of this issue. Wrapping the entire function body in a try/catch does allow you to catch the error but is not tenable.
The unconditional throw you linked at useObservable.ts#L120-L134 is exactly what changed. In non-suspense mode (the default) errors are no longer thrown; they are surfaced via status with the error on error, which is the behavior you asked for:
const{ status,data: users, error }=useFirestoreCollectionData(usersQuery);if(status==='error'){// error is the FirebaseError, e.g. "Missing or insufficient permissions."}
No try/catch needed. Previously status: 'error' was unreachable in practice because the throw happened first.
In suspense mode (suspense: true) errors are still thrown so an Error Boundary can catch them. That is intentional and unchanged.
Please note this ships in 5.0.0, not in any 4.x release, since the change is breaking for anyone currently relying on an Error Boundary in non-suspense mode. See the v4 to v5 upgrade guide for the migration path.
Activity
aadito123 commentedon Sep 6, 2022
I have a similar issue with useFirestoreDocData and useFirestoreDocDataOnce.
The error actually originates from the
SuspenseSubjectclass which throws an error when thevalueproperty is read while the Subject has an error i.e. Firebase Permission Error.This error is also cannot be caught without a React Error Boundary. I think it would be better to pass in a flag like
throwErrorInObservablethat allows it to return theinitialValueor just undefined to represent the error state. Would be more convenient to check for errors synchronously using theerrorattribute in theObservableStatus. I would not mind making a PR for this if maintainers can sign off on it.reactfire/src/SuspenseSubject.ts
Lines 51 to 61 in 9754f86
Another approach could be to not set
hasValueas true when there is an error however it seems that there might be a lot of code already dependent on such behaviour.aadito123 commentedon Sep 13, 2022
tagging @jhuleatt to hopefully increase visibility
jaskaye17 commentedon Dec 3, 2022
Bumping this as well. Crashing on
FirebaseError: Missing or insufficient permissionsrenders this library unusable for me as this is a valid use case which I am unable to handle.utkudotdev commentedon Dec 4, 2022
Same here. Anyone have something on this?
beamercola commentedon Dec 20, 2022
same
jbaldassari commentedon Jan 5, 2023
useFirestoreDocalso has this issue.IAmJamesMudge commentedon Feb 23, 2024
Bump. I can't use this library either because of this issue. Wrapping the entire function body in a try/catch does allow you to catch the error but is not tenable.
rangel-rangelov commentedon Apr 3, 2024
Bump, same here.
samdeen commentedon May 21, 2024
Bump, when will this be fixed?
fix: surface observable errors via status instead of re-throwing
fix: surface observable errors via status instead of re-throwing (#735)
tyler-reitz commentedon Jul 27, 2026
Fixed by #735, merged into the
v5branch.The unconditional throw you linked at
useObservable.ts#L120-L134is exactly what changed. In non-suspense mode (the default) errors are no longer thrown; they are surfaced viastatuswith the error onerror, which is the behavior you asked for:No try/catch needed. Previously
status: 'error'was unreachable in practice because the throw happened first.In suspense mode (
suspense: true) errors are still thrown so an Error Boundary can catch them. That is intentional and unchanged.Please note this ships in 5.0.0, not in any 4.x release, since the change is breaking for anyone currently relying on an Error Boundary in non-suspense mode. See the v4 to v5 upgrade guide for the migration path.