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
In order to ensure asynchronous operation of user workflows, coroutines are implemented in the SDK, which use promises. It is a standard situation when we reject them with internal exceptions, which in some branches may not be handled.
However, in the paradigm of react/promise v3, this is considered undesirable practice. Therefore, when a rejected promise is completed, in which there is no exception handler, the error_log() function is called with the error text.
The side effects of such behavior are unpredictable, and it is currently impossible to disable it.
The issue about unhandled exceptions may be fixed once react/promise has the ability to set a permanent handler, not a one-time one.
Thanks to the tests in roadrunner-temporal, other deviations from the normal operation of the SDK were detected. These tests have been partially transferred to the SDK (see #359).
Therefore, I suggest temporarily abandoning react/promise v3 since version 2.6.1 until a solution is found.
Is there an update on this? I noticed that I had to downgrade react/promise on my project in order to install this SDK. And now I see all kind of Implicitly marking parameter $x as nullable is deprecated errors on PHP 8.4 that are fixed in v3 with reactphp/promise#260.
Regarding deprecations in the SDK, definitely create an issue 👍 . However, deprecations in dependencies should be tracked by the dependencies themselves.
Sure, but in this case, this SDK prevents installation of the latest major, so I think it would have been good if this project created that issue upstream. How else is it going to be fixed?
Yes, it would be great to push the development of React/Promise. However, we still won't achieve the set goals, including those related to the @yield annotation.
Therefore, the most promising direction is to create a fork and maintain our own version of promises compatible with React. However, this is not a priority right now.
Activity
[-]Unhandled Exceptions in Promises with react/promise v3[/-][+]react/promise v3 doesn't work fine[/+]ruudk commentedon May 18, 2025
Is there an update on this? I noticed that I had to downgrade react/promise on my project in order to install this SDK. And now I see all kind of
Implicitly marking parameter $x as nullable is deprecatederrors on PHP 8.4 that are fixed in v3 with reactphp/promise#260.roxblnfk commentedon May 18, 2025
React v3 still has several problems that prevent us from using it.
ruudk commentedon May 19, 2025
I read the issue #359 but saw some follow up PR's, one that introduced a global rejection handler: https://github.com/reactphp/promise?tab=readme-ov-file#set_rejection_handler
Isn't this what was missing?
roxblnfk commentedon May 19, 2025
It's still one-time handler
ruudk commentedon May 19, 2025
Should there be a new issue to track this? I'm a bit surprised that the Temporal SDK has deprecations on PHP 8.4, which was released 6 months ago.
roxblnfk commentedon May 19, 2025
Regarding deprecations in the SDK, definitely create an issue 👍 . However, deprecations in dependencies should be tracked by the dependencies themselves.
ruudk commentedon May 19, 2025
Sure, but in this case, this SDK prevents installation of the latest major, so I think it would have been good if this project created that issue upstream. How else is it going to be fixed?
roxblnfk commentedon May 19, 2025
Yes, it would be great to push the development of React/Promise. However, we still won't achieve the set goals, including those related to the
@yieldannotation.Therefore, the most promising direction is to create a fork and maintain our own version of promises compatible with React. However, this is not a priority right now.