Propagate error if no connection to the message broker could be established #40
Assignees
Labels
Comments
danielwiehl
added a commit
that referenced
this issue
Nov 27, 2020
The Promise returned when starting the platform did not wait until connected to the platform host, preventing the application's proper initialization. When loading manifests took longer than the broker discovery timeout, the platform startup failed at all. This commit solves the following issues: - The Promise returned by `startHost` or `connectToHost` now resolves after successfully connected to the messaging broker. Otherwise, it rejects. - The platform connects to the broker in runlevel 1, that is, after fetched the manifests. Interaction with the broker in lower runlevels is buffered until entering runlevel 1. - We have removed the API to listening for the host platform state, because microfrontends are embedded after the host starts. It was mainly used before introducing the concept of runlevels. - Activator microfrontends are now installed in runlevel 3 to ensure the platform completed startup. closes #40 and #41 Breaking change: The `HostPlatformState` bean has been removed as no longer necessary, because activator microfrontends are now installed after completing host platform startup, and because the startup Promise waits until connected to the host. To migrate: Instead of listening for the host platform to enter the 'started' state, wait for the startup Promise to resolve.
danielwiehl
added a commit
that referenced
this issue
Nov 27, 2020
The Promise returned when starting the platform did not wait until connected to the platform host, preventing the application's proper initialization. When loading manifests took longer than the broker discovery timeout, the platform startup failed at all. This commit solves the following issues: - The Promise returned by `startHost` or `connectToHost` now resolves after successfully connected to the messaging broker. Otherwise, it rejects. - The platform connects to the broker in runlevel 1, that is, after fetched the manifests. Interaction with the broker in lower runlevels is buffered until entering runlevel 1. - We have removed the API to listening for the host platform state, because microfrontends are embedded after the host starts. It was mainly used before introducing the concept of runlevels. - Activator microfrontends are now installed in runlevel 3 to ensure the platform completed startup. closes #40 and #41 Breaking change: The `HostPlatformState` bean has been removed as no longer necessary, because activator microfrontends are now installed after completing host platform startup, and because the startup Promise waits until connected to the host. Note: You can independently upgrade host and clients to the new version because the platform was not using the platform status at all. To migrate: Instead of listening for the host platform to enter the 'started' state, wait for the startup Promise to resolve.
danielwiehl
added a commit
that referenced
this issue
Nov 27, 2020
The Promise returned when starting the platform did not wait until connected to the platform host, preventing the application's proper initialization. When loading manifests took longer than the broker discovery timeout, the platform startup failed at all. This commit solves the following issues: - The Promise returned by `startHost` or `connectToHost` now resolves after successfully connected to the messaging broker. Otherwise, it rejects. - The platform connects to the broker in runlevel 1, that is, after fetched the manifests. Interaction with the broker in lower runlevels is buffered until entering runlevel 1. - We have removed the API to listening for the host platform state, because microfrontends are embedded after the host starts. It was mainly used before introducing the concept of runlevels. - Activator microfrontends are now installed in runlevel 3 to ensure the platform completed startup. closes #40 and #41 Breaking change: The `HostPlatformState` bean has been removed as no longer necessary, because activator microfrontends are now installed after completing host platform startup, and because the startup Promise waits until connected to the host. To migrate: Instead of listening for the host platform to enter the 'started' state, wait for the startup Promise to resolve. Note: You can independently upgrade host and clients to the new version because the platform was not using the platform status at all.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When starting the platform, the returned Promise does not reject if no connection to the message broker could be established, e.g., after the maximal timeout has expired, or in case of rejection by the broker.
MicrofrontendPlatform.startHost(...): Promise<void>MicrofrontendPlatform.connectToHost(...): Promise<void>Expected behavior
The Promise returned by
MicrofrontendPlatform.startHost(...)andMicrofrontendPlatform.connectToHost(...)should reject if no connection to the message broker could be established.1.0.0-beta.7The text was updated successfully, but these errors were encountered: