Vaadin: upgraded from v18 to v21: web ui does not load

Question

I upgraded an existing (and working.) Vaadin application that was using v18.0.2 to v21.0.4, With that new version the server side application starts up as usual, it initializes OK and the first requests triggers the frontend compilation (which also seems to work OK, at least the log shows no abnormalities or errors), but the UI just hangs and fails to load (there is a thin blue progress bar at the top of the page which quickly reaches about 50% of the width. then it gets slower and slower and then starves at about 90% of the screen width).

I don't have the slightest clue in which direction I should check or analyze this. Any suggestion or hint what could be wrong here would be highly appreciated!

If I should attach any config or log details to help analyzing this let me know!

Later addendum: I attach my vaadin_dance.cmd here:

@echo off

:package_entries
set fn=package.json
echo Step 1: Going to remove unsupported Vaadin v19+ entries from %fn%:
pause
rem let user see what we do:
@echo on
type %fn%   | findstr /V /C:"@vaadin/application-theme-plugin" > %fn%_1
type %fn%_1 | findstr /V /C:"@vaadin/stats-plugin"             > %fn%_2
type %fn%_2 | findstr /V /C:"@vaadin/theme-live-reload-plugin" > %fn%_3
type %fn%_3 | findstr /V /C:"@vaadin/theme-loader"             > %fn%_4
rem remove an already existing backup - just in case (if there were one the cp below won't work)
rm %fn%~
rem rename back to original and keep a backup:
cp -b -f %fn%_4 %fn%
rem delete the temp. files":
rm %fn%_?
@echo off
echo unsupported Vaadin v19+ entries removed from %fn%

:local_stuff
echo Step 2: Going to remove project local stuff:
pause
rem let user see what we do:
@echo on
rmdir /S /Q .\target
rmdir /S /Q .\node_modules
rmdir /S /Q .\frontend\generated
rm package.json
rm package-lock.json
rm pnpm-lock.yaml
rm pnpmfile.js
rm tsconfig.json
rm types.d.ts
rm webpack.config.js
rm webpack.generated.js
@echo off
echo project local vaadin-generated stuff removed.

:global_stuff
echo Step 3: Going to remove global stuff: removing pnpm stuff
pause
rem let user see what we do:
@echo on
rm -r -f %USERPROFILE%\.pnpm-debug.log
rm -r -f %USERPROFILE%\.pnpm-state.json
rmdir /S /Q %USERPROFILE%\.vaadin
rmdir /S /Q %USERPROFILE%\.pnpm-store
rem just in case - I encountered them here, too:
rmdir /S /Q D:\.pnpm-store
rmdir /S /Q U:\.pnpm-store
@echo off
echo global vaadin-installed stuff removed.
rem clear (and preload) default repository:

:repo_stuff
echo Step 4: Going to empty m2repository!
pause
rem let user see what we do:
@echo on
rem strange enough I again and again got "access denied" on certain .jars ||-(  So we first take ownership...
takeown /R /F %USERPROFILE%\.m2\m2repository
rem ... before removing the stuff:
rm -r -f %USERPROFILE%\.m2\m2repository\*
@echo off
echo m2repository cleaned.
echo.
pause

The process with the above.cmd file is such, that I run first step 1, then I stop it and try to rebuildv(in a different cmd window). If that does not work, I restart it from begin and run steps 1 & 2, then I stop and try to rebuild, etc. At most after steps 1, 2, 3 & 4 I was (at least so far) always able to rebuild and execute my application. That's at least when build with or reverting to v18.0.3. With v21.x I haven't been successful so far. :-(

Second addendum with the console output:

The application starts up OK (ie without any error message( up to the point where I see "Tomcat has been started on port: ..."

At that point I direct my browser to that port which triggers the dispatching of the DispatcherServlet. That page never loads and the browser times out, but there is NO error message or anything giving a hint re. the type or cause of the problem on the console:

...
2021-12-17 19:36:03,459 INFO  [main] org.springframework.boot.web.embedded.tomcat.TomcatWebServer: Tomcat started on port(s): 8085 (http) with context path ''
2021-12-17 19:36:23,678 INFO  [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-17 19:36:23,682 INFO  [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Initializing Servlet 'dispatcherServlet'
2021-12-17 19:36:23,689 INFO  [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Completed initialization in 2 ms
2021-12-17 19:36:26,103 WARN  [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [2,172] milliseconds.
2021-12-17 19:36:26,103 WARN  [http-nio-8085-exec-3] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [1,457] milliseconds.
2021-12-17 19:36:26,179 INFO  [http-nio-8085-exec-4] com.vaadin.flow.spring.SpringInstantiator: The number of beans implementing 'I18NProvider' is 0. Cannot use Spring beans for I18N, falling back to the default behavior
<Console output stops here and browser times out>

Unfortunately there seems no way to attach screenshots here, so I can't provide the output of the WebDeveloper's Network Tab's output here...

The Browser Inspector Console displays:

Fri Dec 17 2021 19:52:01 GMT+0100 (Central European Standard Time) Atmosphere: unload event vaadinPush-min.js:1:40213
Vaadin push loaded vaadinPush-min.js:1:44231
Failed to register/update a ServiceWorker for scope ‘http://localhost:8085/’: Bad Content-Type of ‘text/html’ received for script ‘sw-runtime-resources-precache.js’.  Must be a JavaScript MIME type.
Uncaught (in promise) TypeError: ServiceWorker script at http://localhost:8085/sw.js for scope http://localhost:8085/ threw an exception during script evaluation.
Path '/login' is not properly resolved due to an error. Resolution had failed on route: '(.*)' vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58:17000
Uncaught (in promise) TypeError: class heritage e is not an object or null
    to http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:1
    266 http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:765
    r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
    promise callback*imports http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    flowInit http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    async*get action/< http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    Z http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    __resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    promise callback*__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    promise callback*a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    promise callback*resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    render http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    __onNavigationEvent http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    setRoutes http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    <anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
    r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
    <anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
    <anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
vaadin-3-1a44b245d20aa3c33130.cache.js:1:153

How is a non-Vaadin intern supposed to decode that stuff and analyse what's going wrong here?

Answer 1

I got the issue replicated and the problem is that in development mode I got a 400 (Bad Request) in the console from Flow.ts with the faulty response Error 400 Invalid location: Location parameter missing from bootstrap request to server.

The fix was to delete the ./frontend/generated folder after which the application worked as it should when running mvn clean jetty:run . But the vaadin:clean-frontend goal should remove the generated folder in frontend which at least for me was the problem.

Check the inspector and look if there is any exceptions in the console.

Answer 2

I just upgraded to v22.01 and with that new version my application works again. Beats me what was broken in versions 19.0.x - 21.0.4 that caused my application to not start up.

While I am happy that my application now works again with the newest Vaadin version, this leaves a pretty bad smell in my mouth. If the only error message one gets is some JavaScript stacktrace gibberish then one stands completely in the rain with this Java-only approach.