Do i have to wrap anything with ..Async in a pcall?

services like datastore(GetAsync,SetAsync etc…) and badgeservice(UserhasbadgeAsync) and marketplace service(UserOwnsGampassAsync) and Playerservice(GetUserIdfromnameAsync)
etc etc. have some sort of async, do i have to wrap them in pcalls?

you don’t have to, but it’d be better if you do.

1 Like

https://developer.roblox.com/en-us/articles/Datastore-Errors

Error Codes

Requests to data stores, like all network calls, may occasionally fail due to poor connectivity or other issues. Wrapping data store commands in pcall() will handle any errors and return a message with an error code that you can cross-reference in the following table.

Anything that makes a web request to a ROBLOX web service might fail, although specific attention is paid to DataStore requests, because those have request limits and throttles that are commonly hit and need special care.

This means yes, wrap everything in a pcall. However, you have to do something with the knowledge that your request just failed. If your DataStore call just failed, then your script should look at the error to see how to deal with it.

For example, if you try to load data and it is implied that the player once had save data, but DataStore is having issues, then you absolutely should not let the player save, because that would overwrite their save data with fresh, empty data when they try to play. If you pcall it and ignore the error, you will get data loss despite having “handled” the error.

I don’t know anything about BadgeService and the others failing, though. But if it’s critical that you know whether a player has a badge or not, and can’t just assume they don’t when the call does fail, then you need to deal with that.

edit: Also, Async means that the method will yield the thread that is currently running. That is, it is exactly like a wait(), except you cannot know exactly how long it will wait for.
DataStore requests may be put in a request queue, which can get up to 30 requests long and make that wait() really, really long.

4 Likes