Opened 3 years ago

Closed 3 years ago

#3462 closed undecided (fixed)

browser doesn't reconnect to master if connection is broken and show empty results instead of errors

Reported by: rutsky Owned by:
Priority: major Milestone: 0.9.0
Version: master Keywords:
Cc: tardyp

Description

Steps to reproduce:

  1. Start master.
  2. Open Web UI.
  3. Restart master.

Try to check in web UI different lists, e.g. list of builders, last changes, workers.

Expected behavior: browser should reconnect and display proper results. At least display that there are errors.

Observed behavior: web UI silently display empty results, i.e. no builders, zero changes, no workers.

Change History (5)

comment:1 Changed 3 years ago by eigenvector

Sorry if this seems like a "me too" comment, but I'm an existing Buildbot 0.8 user who is trying to grab the buildbot 9 sources and figure out how to get up and running with buildbot 9 and I'm finding this to be a hindering issue.

I'm finding it quite confusing that the results being displayed in the web UI don't always update. I'll check in new changes and not see them reflected, Connect new workers and not see them in the worker list. Then when I do 'buildbot stop master' the Web UI does not go completely offline as it would in buildbot 0.8. This makes me wonder, did I not successfully kill the master? Or is there a separate process which is running the UI (via node.js) which needs also to be killed?

So at the moment it's really difficult to me when things are not working because I have my master.cfg set up incorrectly versus just due to some communication difficulties between the web UI and the master.

The web UI really needs to have some more clear diagnostics as to whether the server is up and running. Perhaps if it had a timestamp somewhere that told you the last time it actually communicated with the master, that would be good, just as a sanity check. If I'm starting and stopping the master repeatedly and the web UI says it hasn't heard from the master since yesterday, then I will know that there's some communication problem going on.

comment:2 Changed 3 years ago by anish

Similar note, I have two buildbot instances with the exact same exact config file (one is for testing configuration changes). For no particular reason, the test instance can't be used to trigger forced builds or do rebuilds over vpn, but never has an issue when accessed via a machine directly on the network.

comment:3 Changed 3 years ago by rutsky

  • Milestone changed from undecided to 0.9.0

I set milestone to 0.9.0, @tardyp, please change if you think it's not suites 0.9.0.

comment:4 Changed 3 years ago by tardyp

I think we should provide something better than nothing, but not go to the full fledge solution, which I think will be too risky and add bug.

If there is a websocket disconnection, web browser should reload the page.

comment:5 Changed 3 years ago by tardyp

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.