[Seaside] Interesting Comet failure - should it be more defensive?

[TimM]

This is an interesting continuation of my "Connection Closed" post - but 
this piece sits on the Comet side.

Background: I've been running Pharo Seaside3.0rc3 on my laptop and 
leaving it running in the background while I read about things, browse 
the web and suspend my laptop from time to time etc.

Things have been running well for a day, however this morning I noticed 
two walkbacks in my image, and the root cause seemed to be the 
Socket>>waitForDatFor: method. (which I can understand if I have 
suspend/resumed my laptop)

However if I look at the failure - should Comet be a bit more defensive 
in the following code?

CTPusher>>notifySession
	self session application cache
		notifyRetrieved: self session
		key: self session key

The session application can be nil - and hence a DNU on #cache.

This is recent update Lukas added for a few us playing with Comet (which 
has been working well in my testing).

In #push: he added

...
	success
		ifTrue: [ self notifySession ].
...

And this is where I've hit the problem. It could be that this is an 
artificial example (given my suspend/resume scenario) - but then again, 
could a session expire and give a similar situation?

I can imagine a workaround could be something like:

	success
		ifTrue: [ success := self notifySession ].


And then notifySession could start with:

self session application ifNil: [ ^false ].

But is this a legitimate fix?

Tim

Here's the full trace:

UndefinedObject(Object)>>doesNotUnderstand: #cache
CTHandler>>notifySession
CTHandler>>push:
[] in [] in CTPusher>>push:
Array(SequenceableCollection)>>select:
[] in CTPusher>>push:
[] in Semaphore>>critical:
BlockClosure>>ensure:
Semaphore>>critical:
CTPusher>>push:
CTPusher>>ping