-
Notifications
You must be signed in to change notification settings - Fork 23
fix(externals): mismatched externals caused one-app to fail to start #90
Conversation
2d87ab0
to
f5d553d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the implications of this in production? How will engineers know that a bad module was deployed? What happens on startup if the bad module is the root module?
Since this just logs the errors, they would have to check the server logs to see if anything is wrong. The major sign that something is wrong is that their deployed version wont be reflected when they hit the page the module is on. I haven't tested what would happen if the root module fails on server start, will report back on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unsure if we should reset the polling interval if a module fails to load.
Co-authored-by: Jonny Adshead <JAdshead@users.noreply.github.com>
If we do, the polling will always be 1 second ( or whatever the smallest polling interval is ) because it will repeatedly fail. |
agreed, but if its in a broken state is waiting 5min to long |
return addHigherOrderComponent(loadedModule); | ||
} catch (e) { | ||
// eslint-disable-next-line no-console | ||
console.error(e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add some details/context to this error for the users
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to bloat this PR but we should consider adding URLs to our error messages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, we still need to add integration tests for the new scenarios once this PR gets merged and we update holocron in One App
Co-authored-by: Jonny Adshead <JAdshead@users.noreply.github.com>
A child module that requires an external that is NOT provided by its root module will cause one-app to fail to start up, or fail polling if already running.
Description
This fix works by catching an error that is thrown by
onModuleLoad
, a function passed to holocron from the one-app server. Typically this error would bubble up to one-app, where the module map polling would fail.By catching the error, we are able to ignore the "bad" module by preventing it from being updated in the in-memory module map.
This means that if an existing module is updated to require an external that is NOT provided by the parent, we will use its last stable version until a working version of that module is deployed.
This does not affect the module map polling. It will continue to climb as normal up to the ONE_MAP_POLLING_MAX value.
Motivation and Context
This can prevent developers from starting the one-app server locally if a faulty module is deployed to the environment their one-app-runner config points to. It also prevents other modules from being updated in the module map until the faulty module is corrected.
How Has This Been Tested?
Pending unit tests
Types of Changes
Checklist:
What is the Impact to Developers Using Holocron?