Re: [Twisted-Python] Does anyone know why trunk is failing CI on PyPy 7.3.4?

[Adi Roiban]

Hi Wim,

Thanks for the report

On Tue, 27 Apr 2021 at 08:14, Wim Lewis  wrote:

> TLDR: Twisted appears broken on PyPy 7.3.4 (aka "3.7.10")?
>
> I don't have time right now to set up a PyPy-capable environment and try
> to reproduce this, but perhaps someone does?
>
> Long version:
>
> Trunk has been broken since the last merge a week or so ago, but I
> don't think the breakage is due to that merge.  As an experiment I made
> a PR based off the last successful version of trunk, with a whitespace
> change, and it now fails CI as well. So I think the failure must be due
> to some change that isn't in Twisted or controlled-for by tox.
>
> The failure in all cases is in the pypy-3.7-alldeps-nocov-posix task.
> Unlike our usual CI problems it doesn't seem to be a random failure: it
> fails all the time in the same place. But the place doesn't make sense
> to me. It's in the IRC CTCP tests, and they fail in the same ways each
> time (an expected response is not received).
>
> The pair of CI runs closest to the change are these:
>
> run 5793: https://github.com/twisted/twisted/runs/2328450554
> run 5809: https://github.com/twisted/twisted/runs/2360415474
>
> There are a lot of differences, but sys.version went from 3.7.9 to
> 3.7.10 between those runs, so that seems like the most likely culprit.
>
> Last working:
> >  sys.version  : 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 10:55:52)
> >  [PyPy 7.3.3-beta0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
> >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.9/x64
> >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.9/x64
> >  sys.executable   :
> /opt/hostedtoolcache/PyPy/3.7.9/x64/bin/python
>
> First broken:
> >  sys.version  : 3.7.10 (51efa818fd9b, Apr 04 2021, 11:22:34)
> >  [PyPy 7.3.4 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
> >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.10/x64
> >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.10/x64
> >  sys.executable   :
> /opt/hostedtoolcache/PyPy/3.7.10/x64/bin/python
>
> PyPy's release notes for 7.3.4 don't list anything that jumps out at me:
>
> https://doc.pypy.org/en/latest/whatsnew-pypy3-7.3.4.html
>
> My guess would be some latent timing bug in Twisted that was uncovered
> by pypy execution time changes (I don't imagine that the CTCP code gets
> exercised very heavily these days) or perhaps PyPy got a bug.
>
>
> Wim.
>
>
I have setup a pyp3.7.4 and I can reproduce it.

I see 3 options:

* Option A: Skip those tests on pypy  and open a separate ticket to fix the
test
* Option B: Pin pypy 3.7.9 for GHA and open a separate ticket to fix the
test and unpin it
* Option C: Just fix the tests :)

I am looking at option C for one hour... if I can't find a fix will look
into option A.

Cheers

-- 
Adi Roiban
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Does anyone know why trunk is failing CI on PyPy 7.3.4?

[Adi Roiban]

Hi,

A quick diff to fix it... and a ticket
https://twistedmatrix.com/trac/ticket/10187

I will create a PR and we can refine the fix during the review.


diff --git a/src/twisted/words/protocols/irc.py
b/src/twisted/words/protocols/irc.py
index 75300019b..a97abce2e 100644
--- a/src/twisted/words/protocols/irc.py
+++ b/src/twisted/words/protocols/irc.py
@@ -3678,10 +3678,10 @@ def ctcpExtract(message):
 normal_messages.append(messages.pop(0))
 odd = not odd

-extended_messages[:] = filter(None, extended_messages)
-normal_messages[:] = filter(None, normal_messages)
+extended_messages[:] = list(filter(None, extended_messages))
+normal_messages[:] = list(filter(None, normal_messages))

-extended_messages[:] = map(ctcpDequote, extended_messages)
+extended_messages[:] = list(map(ctcpDequote, extended_messages))


On Wed, 28 Apr 2021 at 10:01, Adi Roiban  wrote:

> Hi Wim,
>
> Thanks for the report
>
> On Tue, 27 Apr 2021 at 08:14, Wim Lewis  wrote:
>
>> TLDR: Twisted appears broken on PyPy 7.3.4 (aka "3.7.10")?
>>
>> I don't have time right now to set up a PyPy-capable environment and try
>> to reproduce this, but perhaps someone does?
>>
>> Long version:
>>
>> Trunk has been broken since the last merge a week or so ago, but I
>> don't think the breakage is due to that merge.  As an experiment I made
>> a PR based off the last successful version of trunk, with a whitespace
>> change, and it now fails CI as well. So I think the failure must be due
>> to some change that isn't in Twisted or controlled-for by tox.
>>
>> The failure in all cases is in the pypy-3.7-alldeps-nocov-posix task.
>> Unlike our usual CI problems it doesn't seem to be a random failure: it
>> fails all the time in the same place. But the place doesn't make sense
>> to me. It's in the IRC CTCP tests, and they fail in the same ways each
>> time (an expected response is not received).
>>
>> The pair of CI runs closest to the change are these:
>>
>> run 5793: https://github.com/twisted/twisted/runs/2328450554
>> run 5809: https://github.com/twisted/twisted/runs/2360415474
>>
>> There are a lot of differences, but sys.version went from 3.7.9 to
>> 3.7.10 between those runs, so that seems like the most likely culprit.
>>
>> Last working:
>> >  sys.version  : 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 10:55:52)
>> >  [PyPy 7.3.3-beta0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
>> >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.9/x64
>> >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.9/x64
>> >  sys.executable   :
>> /opt/hostedtoolcache/PyPy/3.7.9/x64/bin/python
>>
>> First broken:
>> >  sys.version  : 3.7.10 (51efa818fd9b, Apr 04 2021, 11:22:34)
>> >  [PyPy 7.3.4 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
>> >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.10/x64
>> >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.10/x64
>> >  sys.executable   :
>> /opt/hostedtoolcache/PyPy/3.7.10/x64/bin/python
>>
>> PyPy's release notes for 7.3.4 don't list anything that jumps out at me:
>>
>> https://doc.pypy.org/en/latest/whatsnew-pypy3-7.3.4.html
>>
>> My guess would be some latent timing bug in Twisted that was uncovered
>> by pypy execution time changes (I don't imagine that the CTCP code gets
>> exercised very heavily these days) or perhaps PyPy got a bug.
>>
>>
>> Wim.
>>
>>
> I have setup a pyp3.7.4 and I can reproduce it.
>
> I see 3 options:
>
> * Option A: Skip those tests on pypy  and open a separate ticket to fix
> the test
> * Option B: Pin pypy 3.7.9 for GHA and open a separate ticket to fix the
> test and unpin it
> * Option C: Just fix the tests :)
>
> I am looking at option C for one hour... if I can't find a fix will look
> into option A.
>
> Cheers
>
> --
> Adi Roiban
>


-- 
Adi Roiban
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Does anyone know why trunk is failing CI on PyPy 7.3.4?

[Adi Roiban]

Hi

PR at https://github.com/twisted/twisted/pull/1592

I hope we can get a quick review and make the trunk green again :)

Cheeers

On Wed, 28 Apr 2021 at 10:30, Adi Roiban  wrote:

> Hi,
>
> A quick diff to fix it... and a ticket
> https://twistedmatrix.com/trac/ticket/10187
>
> I will create a PR and we can refine the fix during the review.
>
>
> diff --git a/src/twisted/words/protocols/irc.py
> b/src/twisted/words/protocols/irc.py
> index 75300019b..a97abce2e 100644
> --- a/src/twisted/words/protocols/irc.py
> +++ b/src/twisted/words/protocols/irc.py
> @@ -3678,10 +3678,10 @@ def ctcpExtract(message):
>  normal_messages.append(messages.pop(0))
>  odd = not odd
>
> -extended_messages[:] = filter(None, extended_messages)
> -normal_messages[:] = filter(None, normal_messages)
> +extended_messages[:] = list(filter(None, extended_messages))
> +normal_messages[:] = list(filter(None, normal_messages))
>
> -extended_messages[:] = map(ctcpDequote, extended_messages)
> +extended_messages[:] = list(map(ctcpDequote, extended_messages))
>
>
> On Wed, 28 Apr 2021 at 10:01, Adi Roiban  wrote:
>
>> Hi Wim,
>>
>> Thanks for the report
>>
>> On Tue, 27 Apr 2021 at 08:14, Wim Lewis  wrote:
>>
>>> TLDR: Twisted appears broken on PyPy 7.3.4 (aka "3.7.10")?
>>>
>>> I don't have time right now to set up a PyPy-capable environment and try
>>> to reproduce this, but perhaps someone does?
>>>
>>> Long version:
>>>
>>> Trunk has been broken since the last merge a week or so ago, but I
>>> don't think the breakage is due to that merge.  As an experiment I made
>>> a PR based off the last successful version of trunk, with a whitespace
>>> change, and it now fails CI as well. So I think the failure must be due
>>> to some change that isn't in Twisted or controlled-for by tox.
>>>
>>> The failure in all cases is in the pypy-3.7-alldeps-nocov-posix task.
>>> Unlike our usual CI problems it doesn't seem to be a random failure: it
>>> fails all the time in the same place. But the place doesn't make sense
>>> to me. It's in the IRC CTCP tests, and they fail in the same ways each
>>> time (an expected response is not received).
>>>
>>> The pair of CI runs closest to the change are these:
>>>
>>> run 5793: https://github.com/twisted/twisted/runs/2328450554
>>> run 5809: https://github.com/twisted/twisted/runs/2360415474
>>>
>>> There are a lot of differences, but sys.version went from 3.7.9 to
>>> 3.7.10 between those runs, so that seems like the most likely culprit.
>>>
>>> Last working:
>>> >  sys.version  : 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 10:55:52)
>>> >  [PyPy 7.3.3-beta0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
>>> >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.9/x64
>>> >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.9/x64
>>> >  sys.executable   :
>>> /opt/hostedtoolcache/PyPy/3.7.9/x64/bin/python
>>>
>>> First broken:
>>> >  sys.version  : 3.7.10 (51efa818fd9b, Apr 04 2021,
>>> 11:22:34)
>>> >  [PyPy 7.3.4 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
>>> >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.10/x64
>>> >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.10/x64
>>> >  sys.executable   :
>>> /opt/hostedtoolcache/PyPy/3.7.10/x64/bin/python
>>>
>>> PyPy's release notes for 7.3.4 don't list anything that jumps out at me:
>>>
>>> https://doc.pypy.org/en/latest/whatsnew-pypy3-7.3.4.html
>>>
>>> My guess would be some latent timing bug in Twisted that was uncovered
>>> by pypy execution time changes (I don't imagine that the CTCP code gets
>>> exercised very heavily these days) or perhaps PyPy got a bug.
>>>
>>>
>>> Wim.
>>>
>>>
>> I have setup a pyp3.7.4 and I can reproduce it.
>>
>> I see 3 options:
>>
>> * Option A: Skip those tests on pypy  and open a separate ticket to fix
>> the test
>> * Option B: Pin pypy 3.7.9 for GHA and open a separate ticket to fix the
>> test and unpin it
>> * Option C: Just fix the tests :)
>>
>> I am looking at option C for one hour... if I can't find a fix will look
>> into option A.
>>
>> Cheers
>>
>> --
>> Adi Roiban
>>
>
>
> --
> Adi Roiban
>


-- 
Adi Roiban
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] startTLS errors not propagating to Factory

[Richard van der Hoff]

On 28/04/2021 07:06, Glyph wrote:


Is the SMTP code holding the Factory 
wrong? Or is it reasonable to expect the verification error to 
propagate into clientConnectionFailed - in which case, how could this 
work?


Thanks for your thoughts!


Hi Richard,

Sorry for the delayed response here.

This is a bug in Twisted, and I think it boils down to this line: 
https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/protocols/tls.py#L391 



The code as written here appears to be expecting this sequence:

 1. failVerification is called with a reason containing a helpful
OpenSSL verification error
 2. we save that reason as `self._reason` for reporting later, calling
abortConnection()
 3. since the connection got aborted, we expect our underlying transport
to call loseConnection on us
 4. we will then get a falsey reason [?!?!] and as such we will use
self._reason instead


Assumption 4 is nonsense and has never been true within Twisted as far 
as I know; connectionLost always gets a Failure, Failures are never 
falsey, so we will never use self._reason.  To fix this we need to 
actually honor self._reason under the conditions we expect, i.e. it's a 
ConnectionAborted 
https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/internet/error.py#L209 


Thanks very much for your thoughts on this, Glyph - it's always helpful 
to have an insight into the intended design when trying to resolve this 
sort of thing.


I don't follow your reasoning though. I think you might have misread the 
line you point to 
(https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/protocols/tls.py#L391). 
It is "self._reason or reason" - ie, if self._reason is already set, it 
will take precedence over reason.


In my tests at least, TLSMemoryBIOProtocol.connectionLost is doing 
exactly the right thing - it is called with an unhelpful reason, but 
substitutes back in the helpful reason which has already been stashed.


Rather, the problem, as I see it, is that it's not 
TLSMemoryBIOProtocol.connectionLost that calls 
Factory.clientConnectionLost. That is done by tcp.Client.connectionLost, 
via one of tcp.Client's myriad of base classes, at 
https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/internet/tcp.py#L508. 
Of course, that doesn't get the benefit of TLSMemoryBIOProtocol's reason 
switcheroo.


I'm still not quite sure who is in the wrong here.

Cheers

Richard


PS: yes, once we figure out what's going wrong here, I'll at least write 
up an issue...


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Does anyone know why trunk is failing CI on PyPy 7.3.4?

[Glyph]

It's merged.

On Wed, Apr 28, 2021, at 3:07 AM, Adi Roiban wrote:
> Hi
> 
> PR at https://github.com/twisted/twisted/pull/1592
> 
> I hope we can get a quick review and make the trunk green again :)
> 
> Cheeers
> 
> On Wed, 28 Apr 2021 at 10:30, Adi Roiban  wrote:
>> Hi,
>> 
>> A quick diff to fix it... and a ticket 
>> https://twistedmatrix.com/trac/ticket/10187
>> 
>> I will create a PR and we can refine the fix during the review.
>> 
>> 
>> diff --git a/src/twisted/words/protocols/irc.py 
>> b/src/twisted/words/protocols/irc.py
>> index 75300019b..a97abce2e 100644
>> --- a/src/twisted/words/protocols/irc.py
>> +++ b/src/twisted/words/protocols/irc.py
>> @@ -3678,10 +3678,10 @@ def ctcpExtract(message):
>>  normal_messages.append(messages.pop(0))
>>  odd = not odd
>>  
>> -extended_messages[:] = filter(None, extended_messages)
>> -normal_messages[:] = filter(None, normal_messages)
>> +extended_messages[:] = list(filter(None, extended_messages))
>> +normal_messages[:] = list(filter(None, normal_messages))
>>  
>> -extended_messages[:] = map(ctcpDequote, extended_messages)
>> +extended_messages[:] = list(map(ctcpDequote, extended_messages))
>> 
>> 
>> On Wed, 28 Apr 2021 at 10:01, Adi Roiban  wrote:
>>> Hi Wim,
>>> 
>>> Thanks for the report
>>> 
>>> On Tue, 27 Apr 2021 at 08:14, Wim Lewis  wrote:
 TLDR: Twisted appears broken on PyPy 7.3.4 (aka "3.7.10")?
 
 I don't have time right now to set up a PyPy-capable environment and try 
 to reproduce this, but perhaps someone does?
 
 Long version:
 
 Trunk has been broken since the last merge a week or so ago, but I 
 don't think the breakage is due to that merge.  As an experiment I made 
 a PR based off the last successful version of trunk, with a whitespace 
 change, and it now fails CI as well. So I think the failure must be due 
 to some change that isn't in Twisted or controlled-for by tox.
 
 The failure in all cases is in the pypy-3.7-alldeps-nocov-posix task. 
 Unlike our usual CI problems it doesn't seem to be a random failure: it 
 fails all the time in the same place. But the place doesn't make sense 
 to me. It's in the IRC CTCP tests, and they fail in the same ways each 
 time (an expected response is not received).
 
 The pair of CI runs closest to the change are these:
 
 run 5793: https://github.com/twisted/twisted/runs/2328450554
 run 5809: https://github.com/twisted/twisted/runs/2360415474
 
 There are a lot of differences, but sys.version went from 3.7.9 to 
 3.7.10 between those runs, so that seems like the most likely culprit.
 
 Last working:
 >  sys.version  : 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 10:55:52)
 >  [PyPy 7.3.3-beta0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
 >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.9/x64
 >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.9/x64
 >  sys.executable   : 
 > /opt/hostedtoolcache/PyPy/3.7.9/x64/bin/python
 
 First broken:
 >  sys.version  : 3.7.10 (51efa818fd9b, Apr 04 2021, 11:22:34)
 >  [PyPy 7.3.4 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
 >  sys.prefix   : /opt/hostedtoolcache/PyPy/3.7.10/x64
 >  sys.exec_prefix  : /opt/hostedtoolcache/PyPy/3.7.10/x64
 >  sys.executable   : 
 > /opt/hostedtoolcache/PyPy/3.7.10/x64/bin/python
 
 PyPy's release notes for 7.3.4 don't list anything that jumps out at me:
 
 https://doc.pypy.org/en/latest/whatsnew-pypy3-7.3.4.html
 
 My guess would be some latent timing bug in Twisted that was uncovered 
 by pypy execution time changes (I don't imagine that the CTCP code gets 
 exercised very heavily these days) or perhaps PyPy got a bug.
 
 
 Wim.
 
>>> 
>>> I have setup a pyp3.7.4 and I can reproduce it.
>>> 
>>> I see 3 options:
>>> 
>>> * Option A: Skip those tests on pypy  and open a separate ticket to fix the 
>>> test
>>> * Option B: Pin pypy 3.7.9 for GHA and open a separate ticket to fix the 
>>> test and unpin it
>>> * Option C: Just fix the tests :)
>>> 
>>> I am looking at option C for one hour... if I can't find a fix will look 
>>> into option A.
>>> 
>>> Cheers
>>> 
>>> -- 
>>> Adi Roiban
>> 
>> 
>> -- 
>> Adi Roiban
> 
> 
> -- 
> Adi Roiban
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com 
> https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> 
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] startTLS errors not propagating to Factory

[Glyph]

> On Apr 28, 2021, at 2:43 PM, Richard van der Hoff  wrote:
> 
> On 28/04/2021 07:06, Glyph wrote:
>>> Is the SMTP code holding the Factory wrong? Or is it reasonable to expect 
>>> the verification error to propagate into clientConnectionFailed - in which 
>>> case, how could this work?
>>> 
>>> Thanks for your thoughts!
>> Hi Richard,
>> Sorry for the delayed response here.
>> This is a bug in Twisted, and I think it boils down to this line: 
>> https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/protocols/tls.py#L391
>>  The code as written here appears to be expecting this sequence:
>> 1. failVerification is called with a reason containing a helpful
>>OpenSSL verification error
>> 2. we save that reason as `self._reason` for reporting later, calling
>>abortConnection()
>> 3. since the connection got aborted, we expect our underlying transport
>>to call loseConnection on us
>> 4. we will then get a falsey reason [?!?!] and as such we will use
>>self._reason instead
>> Assumption 4 is nonsense and has never been true within Twisted as far as I 
>> know; connectionLost always gets a Failure, Failures are never falsey, so we 
>> will never use self._reason.  To fix this we need to actually honor 
>> self._reason under the conditions we expect, i.e. it's a ConnectionAborted 
>> https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/internet/error.py#L209
>>  
> 
> Thanks very much for your thoughts on this, Glyph - it's always helpful to 
> have an insight into the intended design when trying to resolve this sort of 
> thing.
> 
> I don't follow your reasoning though. I think you might have misread the line 
> you point to 
> (https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/protocols/tls.py#L391).
>  It is "self._reason or reason" - ie, if self._reason is already set, it will 
> take precedence over reason.

Sigh. You're right, I read it backwards.

> In my tests at least, TLSMemoryBIOProtocol.connectionLost is doing exactly 
> the right thing - it is called with an unhelpful reason, but substitutes back 
> in the helpful reason which has already been stashed.
> 
> Rather, the problem, as I see it, is that it's not 
> TLSMemoryBIOProtocol.connectionLost that calls Factory.clientConnectionLost. 
> That is done by tcp.Client.connectionLost, via one of tcp.Client's myriad of 
> base classes, at 
> https://github.com/twisted/twisted/blob/3c868ac11786eef7ea269caa3056f00854128957/src/twisted/internet/tcp.py#L508.
>  Of course, that doesn't get the benefit of TLSMemoryBIOProtocol's reason 
> switcheroo.
> 
> I'm still not quite sure who is in the wrong here.

Aah, yeah, this is a weird quirk of the ancient-style layering in the SMTP code 
:-|.  The way this should work is by using HostnameEndpoint.

I'm not sure exactly where we're going off the rails, but by using both the old 
'startTLS' style of starting a TLS connection, as well as relying on 
ClientFactory rather than an Endpoint of some kind, means that we're getting 
this duplicate notification; the one that you get to Protocol.connectionLost 
will come from TLS and have useful information, but the one that goes to the 
Connector will be coming straight from TCP.

The right thing to fix here, I think, is to ignore clientConnectionLost 
entirely, and instead to have the protocol object relay its failure to some 
other differently-named method on SMTPSenderFactory.

-g

> 
> Cheers
> 
> Richard
> 
> 
> PS: yes, once we figure out what's going wrong here, I'll at least write up 
> an issue...
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python