Opened 3 years ago

Closed 3 years ago

#3567 closed enhancement (fixed)

buildbot nine master trigger traceback in old 'slave'

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

Description (last modified by tardyp)

worker_1   | 2016-06-20 14:50:36+0000 [Broker,client] message from master: attached
worker_1   | 2016-06-20 14:50:36+0000 [Broker,client] Peer will receive following PB traceback:
worker_1   | 2016-06-20 14:50:36+0000 [Broker,client] Unhandled Error
worker_1   | 	Traceback (most recent call last):
worker_1   | 	  File "/usr/local/lib/python2.7/dist-packages/twisted/spread/banana.py", line 153, in gotItem
worker_1   | 	    self.callExpressionReceived(item)
worker_1   | 	  File "/usr/local/lib/python2.7/dist-packages/twisted/spread/banana.py", line 116, in callExpressionReceived
worker_1   | 	    self.expressionReceived(obj)
worker_1   | 	  File "/usr/local/lib/python2.7/dist-packages/twisted/spread/pb.py", line 565, in expressionReceived
worker_1   | 	    method(*sexp[1:])
worker_1   | 	  File "/usr/local/lib/python2.7/dist-packages/twisted/spread/pb.py", line 877, in proto_message
worker_1   | 	    self._recvMessage(self.localObjectForID, requestID, objectID, message, answerRequired, netArgs, netKw)
worker_1   | 	--- <exception caught here> ---
worker_1   | 	  File "/usr/local/lib/python2.7/dist-packages/twisted/spread/pb.py", line 891, in _recvMessage
worker_1   | 	    netResult = object.remoteMessageReceived(self, message, netArgs, netKw)
worker_1   | 	  File "/usr/local/lib/python2.7/dist-packages/twisted/spread/flavors.py", line 112, in remoteMessageReceived
worker_1   | 	    raise NoSuchMethod("No such method: remote_%s" % (message,))
worker_1   | 	twisted.spread.flavors.NoSuchMethod: No such method: remote_getWorkerInfo
worker_1   |

I believe this is a harmless traceback. but still I had to question myself before understanding the problem.

We should use auto-detect method, which does not trigger tracebacks on the old slaves.

One of the easy way is to test slave first, and swallow the traceback inside the buildbot-worker package.

Putting to 0.9.0 as this is the last time we have the change to fix the protocol.

Change History (6)

comment:1 Changed 3 years ago by tardyp

  • Description modified (diff)

comment:2 Changed 3 years ago by dustin

  • Owner set to tardyp
  • Status changed from new to assigned

comment:3 Changed 3 years ago by rutsky

  • Cc rutsky added

comment:4 Changed 3 years ago by rutsky

This is harmless traceback: master tries to call getWorkerInfo() and falls back to getSlaveInfo if former is not available.

I missed that the traceback will arise in this use case, and having tracebacks during normal operation is pretty bad behavior.

Initially I wanted to not include *any* "slave" handling in buildbot-worker, but I don't see any other way to detect which version of slave/worker is used without actually calling getSlaveInfo/getWorkerInfo, also I don't see any option to silence traceback without patching worker, so I assume suggested by Pierre approach with handling getSlaveInfo in buildbot-worker is best way to handle this issue.

comment:6 Changed 3 years ago by tardyp

  • Resolution set to fixed
  • Status changed from assigned to closed

eventually closed by https://github.com/buildbot/buildbot/pull/2294 2287 abandonned

Note: See TracTickets for help on using tickets.