Modern Vespa

It got nicked.

Yeah - I noticed whichever page I was looking at was using XHR rather than fetch().

Let me know if you could use a hand anywhere - I've spent quite a bit of time tinkering in PHP and JavaScript over the years, without being sucked into the "framework du jour" nonsense.

One thought I had was live preview on the posting form, à la Stack Overflow.

Yep. And I strongly prefer fetch(). That said, there are still some valid reasons to use XHR, such as the code I am working on right now -- image upload with progress. The fetch() API supports progress updates, but weirdly not for POST. Thanks!

I am trying to avoid endless frameworks as well. I dislike being at the mercy of someone else's distribution, and I distrust almost everything that I didn't write myself, even if what I write takes longer and is less generalized and has more bugs.

For instance, using jQuery made sense 15 years ago, but I'm slowly trying to eradicate it now. I've replaced several complete jQuery plugins with native JavaScript already, and am working on a few more. Actual WYSIWYG editing is high on my list. Unfortunately, message editing/posting is intertwined with the attachment system, and the one we're using here still has many vestiges of the phpBB attachment mod from 100 years ago, which sucks balls. I hate it so much. I've been putting off replacing it for a decade or so, but am working on a replacement right now.

For actual text editing, there are a couple of JS based libraries that I really like, and have the right mix of features I want (extensibility, for instance) but the one I like the most (EditorJS) has very murky ownership, possibly Russian. I just... yeah.

Firefox (latest version). Single click submission.

Still getting this error message often:

This is definitely a problem I don't understand. Going to have to think about another angle to try to diagnose.

Aight. I've thrown every bit of diagnostic muscle I can think of at this problem. That section of code is now instrumented to within an inch of insanity.

What I'm most interested in learning is the delta between alleged posts -- how much time elapsed between the supposed original post and the duplicate? Was it minutes? seconds? microseconds? I'm now calculating that and logging it.

If the delta is microseconds, it's likely either a double-click or some kind of browser weirdity that is double-submitting the post. In that case, the prudent answer might just be to ignore the second post and take the user straight to the first post (if I can figure out what the first post is in that context -- not sure I can).

If the delta is seconds or minutes, that's a different problem altogether.

So now we wait for it to happen again. (Please feel free to post here if and when it does).

Microseconds.

Will holler next time it happens just in case there is any data that helps ya.

Posting a comment with a pic. Time was normal pic upload duration then failed. Repeat failed. Cut a few pixels and success

I've actually been looking at this problem a bit lately. And it's fairly complex, I think.

In my testing, the only way I can reliably replicate this condition is by doing a reload of the page after transitioning from a GET of the posting page to a POST of the posting page. By that, I mean after doing a preview of the post or pressing the "Add Attachment" button -- both of which will refresh the initial posting page (via a POST request) and remove the query arguments from the site address -- the difference between the two pictures I've shown below.

After doing a Preview or Add Attachment, the query parameters are moved from the GET query string to hidden POST variables. If you hit "Reload" on the page at this point, you're asking the server to load the posting page without telling it what mode you want to be in (new topic, reply, quote, edit, etc) and thus you get the message you are seeing.

The posting page has been like that forever -- dating back to the original phpBB code. And the problem has been happening ever since then, though for some people a lot more than others. I don't have any idea why the difference, though.

For the record, I don't actually think people are hitting "Reload" on the page deliberately when this occurs. Rather, it's my guess that something is causing the page to be reloaded unintentionally. But I honestly don't know what that trigger is. I don't think it's actually anything to do with the image, but I'm willing to be wrong about that.

If you can figure out a way to reliably reproduce the problem (without hitting "reload", that is) then I would be genuinely appreciative. As it is, I'm a bit stumped.

All of this might be a moot point, though -- I am in the process of completely rewriting the posting page, and resilience to reload is the very first thing on my design requirements. In fact, I'd like to be able to leave a post in progress and return to it later (at least within the span of that session, anyway) without any loss.

I think it's simply big pics.

Can you send a pic that reproduces the issue to support@modernvespa.com?

sent (had to wait until I got home from my road trip)

I'm wondering if the "Reply" icon on the Home page broke for NSM? It's staying displayed even though I'm caught up on threads there.

Checked in on my phone (Android 15 w/Chrome) and PC (Win 11 w/Edge) and I get the same behavior.

I noticed it after MJRally replied to the Bollox thread

Lemme check...

Sorry, amended to add better details.

Have you tried hitting the "Mark All Read" button? Could be something on a later page.

That cleared it. Thanks!

I'll remember that trick next time.

Oh good. Thanks for the update.

502 still happening.

Frequency?

first in a while. probably since I last mentioned here.

Got a 502 error when I tried to flag a post as spam (when sending the message). Occurred once with several spam reports.

Is there a way to block a user as long as an active spam report is unprocessed, so that this user cannot post any more?

I'm asking because several spam posts are currently being posted by the same user.

It's possible, but it is also the kind of thing that could be easily abused. The whole report system is likely to be replaced in the near future, though, so I could consider this as a part of that overhaul.

This has also been happening to SteelBytes on occasion. I am honestly clueless as to why -- the server isn't overloaded (ever) so I am not sure why it is having intermittent issues.

Did you post this very close to the time it happened? I am trying to track down the specific log message, but they are organized in very small groups by time & date.

Yes. Screenshot is taken 12:57 German Time (4 Minutes before Post). The error occurred in one of the first spam reports I submitted.

Well, there are several indications that combined almost rule out abuse: New accounts, with no or few posts so far, which start many new topics in a short time or post in short frequencies (in which NO defined keyword or certain keywords appear) and then receive one or more spam reports (possibly from two or more users).

Yes, I was thinking along the same lines. New accounts (created in the last 24-48 hours) would probably be a sufficient clause.

You are currently UTC+1, yes? Not yet Mitteleuropäische Sommerzeit?

Yes, sir! UTC+1, Summertime (UTC+2) is starting end of March.

Thanks much. I found the transaction. Annoyingly, CloudFront logs didn't include the same transaction ID that is in your screenshot. I finally found it by IP address.

It's a 502 error, yes -- but the log didn't reveal anything insightful, unfortunately. I've been trolling the interwebs on and off looking for information about intermittent CloudFront 502 errors, but virtually every documented CloudFront 502 error is due to server configuration errors that prevent any requests from getting through, not just occasional ones.

So I am still stuck.

Thanks for the info, though, it was helpful to track down the log.

SteelBytes provided a pretty good hint a few days back that this problem might have something to do with the keep-alive timeout, which CloudFront sets automatically at 5 seconds. I've been pondering this for a while, and it makes some sense when you consider that Apache's keep-alive timeout is also (allegedly) 5 seconds.

(I say allegedly because I don't actually have any specific keep-alive directives set for Apache, and afaik there isn't a way to ask Apache directly what it is set to -- but it is definitely on, as various empirical tests have confirmed).

So, assuming both the CloudFront proxy and Apache are using a keep-alive of 5 seconds, then the coders reading this might be recognizing a race condition right about now.

My working hypothesis is that if CloudFront and Apache don't agree on exactly when the 5 second timeout starts and ends, then there is a potential case where Apache's 5 seconds might end just before CloudFront's 5 seconds are up, meaning CloudFront is at that point holding a stale connection to the server. And if a request came in just at that moment, and CloudFront found itself with a stale connection, it is plausible that it would get no response from the server and thus respond to the client with a 502 error.

So, what to do?

Rather than increase the keep-alive timeout (on either party) I have opted to lower CloudFront's keep-alive timeout to 4 seconds, and leave Apache's at its (alleged) default of 5 seconds. This should create a bit of margin where CloudFront will negotiate a new connection to the server slightly before Apache has given up on the old connection, which should be perfectly cromulent.

Will this work? I have no idea. I am relying on you two (and anyone else reading this who is adversely affected) to report further 502 errors to me.

Thanks for both of your help so far.

No pic or placeholder?

There is a pic there, but it is blank. I checked the logs, and the user in question did in fact upload an image, and I see no errors or any sign of anything amiss.

Not sure if that was an intentionally blank image upload or if something went wrong.

I've removed the blank avatar, assuming it was unintentional.

Search would be better if there was a filter for "has attachment / picture"

MV often makes it clear that NSR topics are welcome in general discussion. But I noticed the description indicates otherwise:

You know, I don't think I've looked at that description in (checks watch) about 20 years.

Getting this when I try to reply to the "What are you listening to thread" in NSM, as I start typing. About 1 or 2 minutes ago.