Bitten crashes after configuration change

[Emmanuel Blot <manu.blot@…>]

I've changed an active configuration to update the "Oldest revision" field, increasing this revision value (from 4000 to 8000)

After I made this change, I've observed than other configurations - which have not been updated - fail to be 'bittenized' (i.e. built): their pending build number were increasing, following the SVN commits, but got never built at all.

Examining the Trac trace on the master, I've observed the following error:

2009-04-23 14:31:18,539 Trac[main] ERROR: Internal Server Error: 
Traceback (most recent call last):
  File "/local/engine/trac/trac/web/main.py", line 458, in _dispatch_request
    dispatcher.dispatch(req)
  File "/local/engine/trac/trac/web/main.py", line 212, in dispatch
    resp = chosen_handler.process_request(req)
  File "/local/engine/bitten/bitten/master.py", line 81, in process_request
    return self._process_build_creation(req)
  File "/local/engine/bitten/bitten/master.py", line 136, in _process_build_creation
    build = queue.get_build_for_slave(slavename, properties)
  File "/local/engine/bitten/bitten/queue.py", line 143, in get_build_for_slave
    if self.should_delete_build(build, repos):
  File "/local/engine/bitten/bitten/queue.py", line 316, in should_delete_build
    TargetPlatform.fetch(self.env, build.platform).name)
AttributeError: 'NoneType' object has no attribute 'name'

It appears that for some reason I've not investigated, TargetPlatform.fetch(self.env, build.platform) evaluates to None and the code is not robust against this error case.

The "fun" part is that the error simply occurs to log an informational message:

log.info('Dropping build of configuration "%s" at revision [%s] on '
               '"%s" because it is outside of the revision range of the '
               'configuration', config.name, build.rev,
               TargetPlatform.fetch(self.env, build.platform).name)

see trunk/bitten/queue.py#L316​

As a workaround, I've replaced TargetPlatform.fetch(self.env, build.platform).name with a simple conditional instruction, and Bitten now works ok. I'm not sure whether fetch is expected to always return a valid instance or not though.

Trac:	0.12dev-r8139
Python:	2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC 4.3.2]
setuptools:	0.6c8
SQLite:	3.5.9
pysqlite:	2.4.1
Genshi:	0.6dev-r1052
Babel:	-
Pygments:	0.10
Subversion:	1.5.6 (r36142)
jQuery:	1.3.2

[Emmanuel Blot <manu.blot@…>]

Too bad it does not appear in the Trac information box, I use Bitten [629] from the trunk​

[osimons]

I've look at this, but don't quite get what happens here. should_delete_build() is only called from one place in the code, immediately after collecting all pending builds from model.Build.select(). As all pending builds should have a platform, and all platforms have names, I just don't see how this can happen.

And, the really strange thing (if I understand you correctly), is that all OTHER builds fail - you change ConfigC, and then ConfigA + ConfigB fails?

I've not managed to reproduce the error, so any help is much appreciated.

[osimons]

Manu, login on the Bitten project using your regular Edgewall id, and you should now be able to change ticket properties and so on - including assigning this ticket to yourself if you can help out.

[osimons]

See #130 - that patch covers same method.

[osimons]

See also #127 - its attached patch also touches this very same code.

[osimons]

Even #212 adresses this same code, although the circumstances are different (removing/renaming platforms).

Should be able to put something together here, but not sure which ticket(s) to keep open...

[eblot]

Replying to osimons:

Manu, login on the Bitten project using your regular Edgewall id, and you should now be able to change ticket properties and so on - including assigning this ticket to yourself if you can help out.

Ok, thanks (it works)

About the actual error: not sure how this can happen, I'll try to reproduce the error once more - unfortunately, I have no free time by now.

[osimons]

Ah. Got it - platforms may be deleted (and certainly likely for platforms in distant past), and when deleted they are removed completely with no record left in the database.

Closing #212 and #130 (partial) as duplicates of this ticket, and will get a fix committed soon.

[osimons]

This should now be fixed as part of [680].