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

[Sergey Schetinin]

On Thu, Nov 13, 2008 at 02:27, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

It would make sense if the _need_init changes weren't rolled back, but
I see no other reason.

> 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.

I can write one for this case, but the only part I'm not sure about is
how to reliably force rules to roll back?