[Feature Request] - es_extended - Add promise for getSharedObject to wait until it's fully ready

[s1nyx]

Hi,

Describe the Feature Make getSharedObject export waiting for es_extended to be fully initialised using lua-promise package integrated by default on FiveM.

Screenshots I am referring to the fact that the export should return the value only when the function making ready es_extended is finished.

es_extended/server/common.lua:

Additional context Needed because otherwise we have to do while .. do and it's annoying and clearly not a good practice.

Have a nice day.

[Gellipapa]

@s1nyx Hi! Can you send me a reproduction code for testing? Thanks

[s1nyx]

@s1nyx Hi! Can you send me a reproduction code for testing? Thanks

Hi,

I mean you just have to call the getSharedObject export before es_extended it is fully initialised. So to reproduce it, you can add a Wait() in the MySQL.ready callback in order to simulate an issue like a query is taking a long time to respond blocking the es_extended runtime.

[Gellipapa]

@s1nyx Hi! Can you send me a reproduction code for testing? Thanks

Hi,

I mean you just have to call the getSharedObject export before es_extended it is fully initialised. So to reproduce it, you can add a Wait() in the MySQL.ready callback in order to simulate an issue like a query is taking a long time to respond blocking the es_extended runtime.

Yes I understand that, but in your case where did this happen I was wondering if it was a code snippet where you experienced this in use.

[Gellipapa]

@s1nyx Hi! I looked into your problem, but the promise can't be solved this way, because it's ok not to return the export value until then, but since the export value is nil, it throws the error that ESX= nil, this can be solved by putting it in a thread, because then you have to handle the asynchronicity not only at the export level but also within the given script to avoid these NIL errors.

But I'm waiting for your code snippet to see where exactly this was a problem for you.

[s1nyx]

@s1nyx Hi! I looked into your problem, but the promise can't be solved this way, because it's ok not to return the export value until then, but since the export value is nil, it throws the error that ESX= nil, this can be solved by putting it in a thread, because then you have to handle the asynchronicity not only at the export level but also within the given script to avoid these NIL errors.

But I'm waiting for your code snippet to see where exactly this was a problem for you.

Hi,

I can't give you a snippet because this depend on how much time es_extended takes to load fully and the difference between when the script has been started and when the export has been called.

I know how to solve this issue easily on my scripts however I shouldn't have to do it at all. The issue is not about ESX=nil, it's just some variables included in the table which are not synchronized yet (like the jobs for examples). So in my library script I need to block my framework detector until some of the variables got synchronized and I shouldn't have to do that.

That's why I need a promise.

I mean I don't see why you don't want to wait until es_extended if fully sync before sending the return value for the export getSharedObject.

[Gellipapa]

Hi! @s1nyx Because it doesn't block the whole process, so if you wait for the init to run completely and then set the promise with resolved then in the other script where you already use ESX as export it will throw NIL on the first occurrence and since there is no hot reload in lua it won't run again by itself, so it would need a script restart to get the value.

In each file the export will put the ESX objectum in, if I do an ESX.getConfig() directly afterwards it will break the script because at that point the init is not done so the export will return a NIL and so there will be no getConfig so the script will break.