(In reply to Ping Chen (:rnons) from comment #6)
The patch fixes comment 3, not sure about the original reported bug.
When applying the (rebased) patch to a 102 build, it doesn't fix the problem. Some observations:
Removing that line 269 slightly changes the behaviour reported in comment #0: The TypeError no longer occurs at line 236, but sending still fails. So there seem to be two issues here: 1) For some reason which wasn't addressed yet, only in the JS module sending fails after going back online. 2) After that, the error handling leads to an additional TypeError.
Reproducing the issue with both send and nntp loglevels at All, we see:
10:15:12.007 mailnews.send: Delivering news message MessageSend.jsm:1084:25
10:15:12.007 mailnews.send: notifyListenerOnStartSending MessageSend.jsm:373:25
10:15:12.008 mailnews.nntp: Connecting to news://news.eternal-september.org:119 NntpClient.jsm:103:20
10:15:12.099 mailnews.nntp: Connected NntpClient.jsm:121:18
10:15:12.119 mailnews.nntp: S: 200 reader01.eternal-september.org InterNetNews NNRP server INN 2.8.0 (20220715 snapshot) ready (posting ok)
10:15:12.120 mailnews.nntp: C: POST NntpClient.jsm:251:20
10:15:12.161 mailnews.nntp: S: 340 Ok, recommended Message-ID <firstname.lastname@example.org>
10:15:12.205 mailnews.nntp: S: 441 You are not allowed to post to alt.de.test
10:15:12.206 mailnews.nntp: Done with status=2147500037 NntpClient.jsm:829:18
10:15:12.206 mailnews.send: OnStopRunningUrl; exitCode=2147500037 MessageSend.jsm:1329:25
10:15:12.206 mailnews.send: Delivery exit processing; exitCode=2153066726 MessageSend.jsm:552:25
10:15:12.206 mailnews.send: notifyListenerOnStopSending; status=2153066726 MessageSend.jsm:500:25
So the server indeed returns
441 You are not allowed to post to alt.de.test, however, in general, the account is set up to post there, as this successful log shows when posting while already online:
10:20:01.354 mailnews.send: Delivering news message MessageSend.jsm:1084:25
10:20:01.355 mailnews.send: notifyListenerOnStartSending MessageSend.jsm:373:25
10:20:01.355 mailnews.nntp: C: POST NntpClient.jsm:251:20
10:20:01.398 mailnews.nntp: S: 340 Ok, recommended Message-ID <email@example.com>
10:20:01.689 mailnews.nntp: S: 240 Article received <firstname.lastname@example.org>
10:20:01.689 mailnews.nntp: Done with status=0 NntpClient.jsm:829:18
this._userIdentity = userIdentity;
console.log("=== 1", userIdentity, accountKey);
this._accountKey = this._getAccountKey(accountKey, userIdentity);
console.log("=== 2", userIdentity, accountKey);
createAndSendMessage we see correct identity and account key when sending online and also when coming back from offline. So the wrong identity/account doesn't appear to be the issue here (and yes, the bug was hijacked ;-)).
This is a bit puzzling. Looking closely at the debug output, in the bad case there the connection is established first with server reply
S: 200, which doesn't happen in the good case since the connection already exists.
If looks like establishing the connection after going back online doesn't work. This suspicion is also confirmed by:
Go offline, prepare message, send later, go online, send unsent - failing
Go offline, prepare message, send later, go online, do not send unsent yet, get messages, sent unsent messages - working.