[PEAK] Re: Trellis: Sensor.listening and iter_listeners()

[Phillip J. Eby]

At 08:33 PM 11/12/2008 +0200, Sergey Schetinin wrote:
>The problem is caused by initialization not being undo-logged, so when
>the rule is initialized, its _process_reads sets .next_listener of
>some Sensor, but the Link creation is not undo-logged. Later, it all
>gets rolled back, and the schedule(self.update_connection) vanishes
>from the ctrl.commit, but the .next_listener is not rolled back, so
>next time the dependency is recreated was_seen is True and the
>_set_listener decides there's no need to schedule update_connection,
>so it never runs. Removing one "if undo" condition in final part of
>the _process_reads fixes the problem. Trellis test suite never passes
>for me (hangs up on "testSequentialCalls
>(test_trellis.TestReactorEventLoop) ..."), so I'm not sure if this
>breaks anything else.
>
>Initialization is once again a culprit of a hard to detect bug. =)

Stranger still, I can't figure out what this suppression of 
undo-logging was added to fix.  Removing both "if undo" conditions 
doesn't break any current tests.  I don't see why it would be useful 
to not roll back such linkages, since reference freshness is handled 
by not dropping links.

I think this might have been another instance of being led astray by 
false analogy, that in initialization we want to pretend things 
happened in a previous transaction.  But the actual approach used 
here doesn't make any sense.

Very shortly after the "if undo"s were added, I made a fairly 
significant change to how rule rollback was handled, and I dropped 
some code from a newly added test that was probably driving the need 
for the if-undos.

However, it'd still be nice to have something in the tests that 
covered the undo-of-initialization case, and one to cover the sensor 
bug in particular.