[FOLIO-1434] UI fails to display Created: 22/Aug/18  Updated: 12/Nov/18  Resolved: 22/Aug/18

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P2
Reporter: Marc Johnson Assignee: Marc Johnson
Resolution: Done Votes: 0
Labels: sprint45
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint:

 Description   

As reported by Zak Burke, folio-testing (and now folio-snapshot) fail to display any UI at all.

Steps to reproduce
1. Visit http://folio-testing.aws.indexdata.com/

Expected result: Display login page
Actual result: blank page

Additional information
The following error is presented in the javascript console:

Uncaught TypeError: Object prototype may only be an Object or null: undefined
    at setPrototypeOf (<anonymous>)
    at dedupLink.js:6
    at dedupLink.js:16
    at Module.<anonymous> (dedupLink.js:15)
    at a (bootstrap:63)
    at Object.<anonymous> (react-apollo.browser.umd.js:2)
    at a (bootstrap:63)
    at Object.<anonymous> (Root.js:8)
    at a (bootstrap:63)
    at Object.<anonymous> (gatherActions.js:7)


 Comments   
Comment by Zak Burke [ 22/Aug/18 ]

Maybe related? While this response refers specifically to Angular, circular dependencies are a theme when searching for this error message.

I updated from CLI 1.2.1 to 1.4.5 yesterday and I started getting warnings that circular dependencies were detected and I started getting that same Uncaught TypeError: Object prototype may only be an Object or null: undefined error allover again when running in --aot mode.

I ended up dropping all my barrel files and switched to direct file imports and that resolved both the circular dependency warnings and the --aot error from this issue. I thought I'd share this in case someone else is struggling with the same problem.

Comment by Marc Johnson [ 22/Aug/18 ]

Zak Burke I think that could be a good hypothesis to explore. If so, we could start by trying to figure out what dependencies have changed

I think when you tried it locally yesterday, the folio-testing-platform didn't exhibit this behaviour?

Comment by Zak Burke [ 22/Aug/18 ]

Correct, I cannot replicate this behavior locally, but I'm not certain I have all the same build parameters in place when I try this locally. diff’ing the output from /_/proxy/tenants/diku/modules on folio-testing and folio-snapshot shows a few things that may be related, maybe, hopefully:

$ diff testing.txt snapshot.txt 
58c58
<   "id" : "mod-configuration-4.0.4-SNAPSHOT.41"
---
>   "id" : "mod-configuration-4.0.4-SNAPSHOT.42"
64,65d63
<   "id" : "mod-graphql-0.1.1000123"
< }, {
84,85d81
<   "id" : "mod-user-import-3.1.0-SNAPSHOT.28"
< }, {
Comment by Zak Burke [ 22/Aug/18 ]

Diffs in the yarn.lock files may be more relevant:

$ diff testing.yarn.lock.txt snapshot.yarn.lock.txt 
1047,1048c1047,1048
<   version "9.1.3"
<   resolved "https://registry.yarnpkg.com/autoprefixer/-/autoprefixer-9.1.3.tgz#bd5940ccb9d1bfa3508308659915f0a14394c8d5"
---
>   version "9.1.2"
>   resolved "https://registry.yarnpkg.com/autoprefixer/-/autoprefixer-9.1.2.tgz#73672614e3ee43a433b84c1c2a4b1ca392d2f6a1"
1051c1051
<     caniuse-lite "^1.0.30000878"
---
>     caniuse-lite "^1.0.30000877"
2074c2074
< caniuse-lite@^1.0.0, caniuse-lite@^1.0.30000844, caniuse-lite@^1.0.30000876, caniuse-lite@^1.0.30000878:
---
> caniuse-lite@^1.0.0, caniuse-lite@^1.0.30000844, caniuse-lite@^1.0.30000876, caniuse-lite@^1.0.30000877:
8076,8077c8076,8077
<   version "4.17.1"
<   resolved "https://registry.yarnpkg.com/webpack/-/webpack-4.17.1.tgz#0f026e3d823f3fc604f811ed3ea8f0d9b267fb1e"
---
>   version "4.17.0"
>   resolved "https://registry.yarnpkg.com/webpack/-/webpack-4.17.0.tgz#7e8df9529dd5fca65c700b3341a001aeae27c749"
[07:28] zburke@lib-zdb9-maclap /Users/zburke/temp 
Comment by Marc Johnson [ 22/Aug/18 ]

It would appear the hosted environments are now displaying the UI now.

We don't know what the cause of this temporary failure is.

Zak Burke Could it be webpack 4.17.1 resolved an issue (although, the latest release is 4.17.10, I wonder why we aren't using that)?

Comment by Zak Burke [ 22/Aug/18 ]

Yes, Marc Johnson, a buggy webpack release is the likely culprit here. v4.17.0 was released yesterday and patched to v4.17.1 24 hours later, which is why last night's build with v4.17.0 failed and this morning's with v4.17.1 succeded. From the webpack releases page:

v4.17.1 / 2018-08-22T09:52:27Z
Bugfixes: fix missing reexports in export * in a concatenated module

v4.17.0 / 2018-08-21T08:43:06Z
Features: allow to provide custom functions to IgnorePlugin
Generated at Thu Feb 08 23:13:18 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.