Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sap.ui.core.Fragment.load is never rejected #3128

Closed
iljapostnovs opened this issue Jan 13, 2021 · 2 comments
Closed

sap.ui.core.Fragment.load is never rejected #3128

iljapostnovs opened this issue Jan 13, 2021 · 2 comments

Comments

@iljapostnovs
Copy link

iljapostnovs commented Jan 13, 2021

OpenUI5 version: 1.85.0

Steps to reproduce the problem:

  1. Load non-existent fragment using sap.ui.core.Fragment.load

This issue is relevant not only for non-existent fragments, but e.g. network issues. If Fragment is not loaded because of the network, error never appears and the app just stays hanging in the busy state (if setBusy was used).

  1. Promise is returned, however it's never rejected if error appears

What is the expected result?
Promise should be rejected in case of errors

What happens instead?
Nothing, promise stays in "pending" status forever.

Any other information? (attach screenshot if possible)
I believe that the issue starts in the sap.ui.core.Fragment.load:
image
↑ .catch is not implemented, but even if it would:
image
↑ reject is not implemented, but even if it would:
image
↑ .catch is not implemented, but even if it would:
image
.catch is not implemented, and here finally we have reject implemented:
image

@flovogt
Copy link
Member

flovogt commented Jan 13, 2021

Hi @iljapostnovs,

Thank you for sharing this finding. I've created an internal incident 2180024521. The status of the issue will be updated here in GitHub.

All the best,
Florian

@H4ze
Copy link
Member

H4ze commented Jan 19, 2021

Hi @iljapostnovs,

Thank you for your analysis. We created a fix which will propagate the promise rejection properly to the outer promise with commit c98e22f, internal code review 5118797 by @Thodd. The change should be available with release 1.87.

Best regards,
Johannes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants