Heatmap loads forever + Repository list fails to load entirely

[theAkito]

• Gitea version (or commit ref): c97433d
• Git version: 2.20.1
• Operating system:

Component	Version
Kernel	4.19.0-8-amd64 x86_64
Distro	Debian GNU/Linux 10 (buster)

• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:
  All good.

Description

• Heatmap and repository list does not load, at all.
• Restarting Gitea or anything like that did not work.
• Error occured after upgrading from 68e4f4e to c97433d.
• Unrelated to Error 500: Heatmap and Repo List Not Loading #8673.

Web Console

TypeError: Illegal constructor. index.js:2429:20
    e index.js:2429
    c runtime.js:45
    _invoke runtime.js:271
    t runtime.js:97
    n asyncToGenerator.js:3
    s asyncToGenerator.js:25
    exports asyncToGenerator.js:32
    exports asyncToGenerator.js:21
    jQuery 2
        l
        c
Service worker event waitUntil() was passed a promise that rejected with 'TypeError: Cache got basic response with bad status 404 while trying to add request https://domain.tld/js/clipboard.js'. serviceworker.js:52:8

Screenshots

[jolheiser]

Have you tried forcing a cache reload? Or un-registering the serviceworker and letting it re-install?

[theAkito]

@jolheiser
No, did not try that, yet. How would I go about doing that?

Meanwhile, I got the old binary back and use this one in the new installation and all is back to normal, as long as this issue ain't fixed, yet.

[silverwind]

Was this built from source? Does public/js/clipboard.js exist in your source checkout?

[theAkito]

@silverwind

Yes. I have an update.sh that I use to update Gitea successfully since more than a year. It fetches the newest sources, gets dependencies, etc. then it builds everything from source.

Does public/js/clipboard.js exist in your source checkout?

Yes.

[silverwind]

Try starting up once with ui.USE_SERVICE_WORKER = false, open the page and then with true again, this should unregister/re-register the service worker.

There is a underlying bug somewhere, but I wonder if SW re-registration helps any or if the error is persistent.

[theAkito]

@silverwind

Well, turns out, that I changed my update.sh script and forgot to add a go get ... line. I updated most of the dependencies and stuff works now. Thanks everyone.

That said, I encounter 2 other errors when trying to fetch dependencies using go get...:

1. Module Path Error - "github.com/nats-io/nats.go" go-kit/kit#940
2. v1.7.10 requires a module by the wrong version influxdata/influxdb#16901

I wasn't able to fix No2, because I don't know which mod/depedency depends on influxdb as a mod/depedency. Therefore I can't fiddle with the go.mod, etc. I just know the most basic stuff about Go, so maybe someone of the more experienced people here could easily solve this.

[silverwind]

Weird that go dependencies would cause JS errors, I don't believe it. Maybe your build was just unclean. Regarding go modules, I don't think you actually need to go get as we vendor them all inside the repo currently.

[theAkito]

@silverwind

So the go get ... is redundant?

Maybe your build was just unclean.

Certainly cannot guarantee it wasn't, however it never caused any remarkable issue, like this one.
That said, if it was unclean, it's probably still unclean, as I didn't change the folder or anything like that. All I did was:

1. go get ... 'ing around
2. re-building the binary, after inability to fix the influxdb issue
3. re-running the newly created binary

So, at least it appears to be connected to dependencies, though I wouldn't know how to confirm it.

[silverwind]

Regarding cleaning: Running make clean-all should get you absolutely clean minus node_modules which you can optionally delete too, so rm -rf node_modules && TAGS=bindata make clean-all build should suffice.

I'm no expert on go build, but I've been building without any go get a long time now.

[theAkito]

@silverwind

I've been building without any go get a long time now.

Same here. I just didn't know about the vendoring possibility.

Regarding cleaning: Running make clean-all should get you absolutely clean minus node_modules which you can optionally delete too, so rm -rf node_modules && TAGS=bindata make clean-all build should suffice.

Should this be run before every new build?

[silverwind]

Ideally, our make process should figure out what needs rebuilding but to avoid any potential bugs in that complex process, it never hurts to clean-all. Build will of course take a minute or two longer.

[silverwind]

Please close if resolved.

[theAkito]

Big thank you to everyone involved in helping!