Tool checker throwing errors
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Billinghurst
	Jun 2 2015, 1:09 PM

Description

Hi @yuvipanda, following recent upgrades at Labs the tool "checker" [1] has started to throw errors though there has been no changes in code

A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred.
 /data/project/checker/venv/local/lib/python2.7/site-packages/flup/server/fcgi_base.py in run(self=<flup.server.fcgi_base.Request object>)
  556         """Runs the handler, flushes the streams, and ends the request."""
  557         try:
=>  558             protocolStatus, appStatus = self.server.handler(self)
  559         except:
  560             traceback.print_exc(file=self.stderr)
protocolStatus undefined, appStatus undefined, self = <flup.server.fcgi_base.Request object>, self.server = <flup.server.fcgi.WSGIServer object>,  self.server.handler = <bound method WSGIServer.handler of <flup.server.fcgi.WSGIServer object>>
/data/project/checker/venv/local/lib/python2.7/site-packages/flup/server/fcgi_base.py in handler(self=<flup.server.fcgi.WSGIServer object>,   req=<flup.server.fcgi_base.Request object>)
 1122                             write(data)
 1123                     if not headers_sent:
=> 1124                         write('') # in case body was empty
 1125                 finally:
 1126                     if hasattr(result, 'close'):
write = <function write>
/data/project/checker/venv/local/lib/python2.7/site-packages/flup/server/fcgi_base.py in write(data='')
 1063         def write(data):
 1064             assert type(data) is str, 'write() argument must be string'
=> 1065             assert headers_set, 'write() before start_response()'
 1066 
 1067             if not headers_sent:
headers_set = []

<type 'exceptions.AssertionError'>: write() before start_response()
    args = ('write() before start_response()',)
    message = 'write() before start_response()'

Also the url with a terminating / [2] now has a redirect error. @Legoktm said that we should seek your input in looking to a resolution

[1] https://tools.wmflabs.org/checker
[2] ] https://tools.wmflabs.org/checker/

The tool is used for works at the Wikisources to identify the status of transclusions of Index: files.

Thanks for any help that you can provide.

Event Timeline

Billinghurst created this task.Jun 2 2015, 1:09 PM

Billinghurst raised the priority of this task from to Needs Triage.

Billinghurst updated the task description. (Show Details)

Billinghurst added a project: VPS-Projects.

Billinghurst added subscribers: Billinghurst, yuvipanda, Legoktm.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 2 2015, 1:09 PM

@MZMcBride adding to ticket

When did this stop working?

Looks to be by 15 May [1]

[1] https://en.wikisource.org/wiki/Wikisource:Scriptorium/Help#Page_Checker_gadget_-_page_is_not_directing_properly_._._._again

Thanks for filing this, @Billinghurst.

Over the weekend, I tried all sorts of commands to try to revive the tool, but none of them were successful. I also looked at various logs in /data/project/checker on tools-bastion-01 but I discovered nothing useful. Some of the commands I tried:

webservice --release=trusty uwsgi-python restart
webservice2 --release=trusty lighttpd restart
webservice2 --release=trusty uwsgi-python restart
webservice2 uwsgi-python restart
webservice2 lighttpd restart

&c.

It's really, really frustrating that a very simple app like this can't simply be set up on Tool Labs and then be left alone with the expectation that it will continue to work indefinitely. This tool is essentially a rudimentary CGI script that executes a small amount of Python.

I honestly can't fathom why keeping a small Web application like this running is so difficult. It's a Web server. You start it, get your app set up, and then leave everything alone and it should just continue to work. How is this tool suddenly broken again? This is the second or third time this year I've had to debug this stupid tool.

I see an @app.route('') in the code that is causing:

Traceback (most recent call last):
  File "/data/project/checker/www/python/src/app.py", line 139, in <module>
    @app.route('/')
  File "/data/project/checker/www/python/venv/local/lib/python2.7/site-packages/flask/app.py", line 1013, in decorator
    self.add_url_rule(rule, endpoint, f, **options)
  File "/data/project/checker/www/python/venv/local/lib/python2.7/site-packages/flask/app.py", line 62, in wrapper_func
    return f(self, *args, **kwargs)
  File "/data/project/checker/www/python/venv/local/lib/python2.7/site-packages/flask/app.py", line 976, in add_url_rule
    rule = self.url_rule_class(rule, methods=methods, **options)
  File "/data/project/checker/www/python/venv/local/lib/python2.7/site-packages/werkzeug/routing.py", line 540, in __init__
    raise ValueError('urls must start with a leading slash')
ValueError: urls must start with a leading slash

I think that's a problem with the code?

^ was on doing a webservice uwsgi-python start, which is what @Legoktm told me this was running on.

yuvipanda renamed this task from Tool checker throwing errors following labs changes to Tool checker throwing errors.Jun 2 2015, 2:54 PM

yuvipanda edited projects, added Tools; removed Toolforge.

yuvipanda unsubscribed.Jun 2 2015, 3:00 PM

So...I added the @app.route('') while debugging and forgot to remove it :/

Somehow the webserver was started as lighttpd instead of uwsgi-python, and something about the service manifest. So Yuvi fixed it with rm service.manifest && webservice uwsgi-python start. The former should be unnecessary, Yuvi will look into why later.

Tool checker throwing errorsClosed, ResolvedPublicActions

Description

Event Timeline

Tool checker throwing errors
Closed, ResolvedPublic
Actions