Subtle changes, bugs and feedback

It's in blue. Like a link.

Also, clicking on the thread title should take you to your last read position in the thread.

which doesn't use email address as username

Yup, that's the bit.

Either we own the authentication of a username and password, and the inherent risks of then being an identity provider (i.e. all previous versions of this forum based on vBulletin and Vanilla experienced security breaches with total loss of their user database, email addresses and passwords)... or we do what we are doing, which is to rely on external identity providers via Auth0 and OpenID Connect (Google, Microsoft)... and then we get the benefit of their security teams and processes, and can be sure that we cannot leak passwords and won't appear on a haveibeenpwned announcement.

But... the side effect of external authentication as an async process... it is async, and so there isn't a trivial way to block things and force something like there is when you try and run security yourself.

When I made this choice I prioritised account and data security over convenience and control, accepting at the time that the default username thing was an ugly compromise in favour of security.

there isn't a trivial way to block things and force something

There probably is a fairly trivial way to draw people's attention to the fact that they can customise their username. People are generally both thick and incurious, so it won't occur to most of them that they can do it, and they won't be able to work out how to do it unless you put a step by step guide right in front of them

Pull requests accepted.

It's in blue. Like a link.

So are all the other links. The "replied" one has the nice property of taking you to the latest post in the thread, which is why I suggested distinguishing it in some way.

Also, clicking on the thread title should take you to your last read position in the thread.

Not if one uses a browser without logging in, then it takes you to the beginning of time.

Not if one uses a browser without logging in, then it takes you to the beginning of time.

Yup.

The last read state needs to be stored somewhere, and in the browser is a bad choice as people want it to work across devices, i.e. if I read this on a desktop and then catch up on my mobile, then it should pick up last read properly and not jump back to the last time I looked on my mobile.

But then I need to store the state against something... i.e. against the profile. Which of course we don't have for guests.

I'm not sure whether this is a forum issue or, I suspect, a browser one.

Using Chrome, clicking "in reply to", etc brings me to the correct message, using Firefox it doesn't.

I think it's to do with images loading and knocking the page out of alignment, the issue is bigger with pages with lots of images but I'm not sure why it's a problem for Firefox and not Chrome. Any broswer settings that can be changed if it isn't a forum issue?

Assume this is the right place to put this, apologies if not

For some reason I can't see Miscellaneous and Meaningless, or search for anything I've posted in that area. Have tried Edge and Chrome on both PC/Mobile, same issue. Can still access via URL and post, though.

Have you accidentally put it on ignore? Check your ignore list.

And that'll be that! Cheers, no idea how that happened

Just ignore it and it'll go away.

The outage this morning was a subtle change.

From 09:13 - 09:45 BST I created and moved a couple of servers.

I've nuked the Ubuntu 14.04 API and database servers, including the PostgreSQL 9.2 instance that had run for the last 7 years with no upgrades.

I've created a new and hardened Ubuntu 20.04 server with PostgreSQL 14 and the latest version of microcosm.

The new server was needed as we were facing a disk space crunch on the old server and also running way too hot (hence not being as snappy as the site used to be).

So we've also gone from 4 virtual CPU cores to 8 dedicated CPU cores.

During this move I did lose 2 comments due to a timing error on starting the database backup and the existing service not being shut down quickly enough. Apologies to whomever made those... they're gone in the very quick shuffle of the scripts working and I only know they happened as the nginx logs in front of everything showed 2 succcessful HTTP POST requests.

Anyhow, server surgery done.

I thought the end of days were upon us when the forum went down.
Thanks for keeping this place going

Thanks for the explanation.
When I receive the server error notification, I always expect it is something 'wrong' at my end,
be it laptop or mobile,
but,
then remembered reading one of your recent posts about needing to upgrade stuff,
(beyond my comprehension).
Thanks for the update, and all the work you do behind the scenes to keep this forum going.
(If you ever get to a Wests there are some cracking Newton Wonder apples on offer at the moment.
I'm certain you could make yourself a passable apple crumble in your new kitchen).

I thought the end of days were upon us when the forum went down

I do like to keep it a rarity.

It's so damn reliable normally that if I see outages elsewhere on the internet I check whether LFGSS is up and snappy to get an idea of how bad the outage is. This site has very few dependencies and a hell of a reliable and secure set up.

if I see outages elsewhere on the internet I check whether LFGSS is up

It's my go to test page if something isn't loading properly too.

Yep same - is it my connection or this page? Check lufguss.

https://www.lfgss.com/comments/16243013/

https://www.lfgss.com/comments/16225460/

What are these? My completely baseless guess is some sort of non-compliant Apple implementation of strikethrough?

2 Attachments

Combination of non-standard thing by whatever device posted it... and your device not supporting whatever it is.

But yes, it's a strikethrough.

I'm on Chrome/Android. Interestingly if I copy that text it shows up as strikethrough in my clipboard or in Chrome. If I paste it into Google it works. When pasted into a comment here the Xs appear.

£̶3̶0̶

Can anyone else see them or is it my device only?

2 Attachments

One of the cleanup cron jobs has been stuck the past few days.

I've disabled it, but it appears to have got itself into a strange locked state which prevented the Following page from correctly displaying for users... actually it just didn't display for some users as their rows were locked.

To allow the read path to work again, I've deleted some rows from the table. This is OK (from my perspective) as the following table contains a high number of duplicates.

But... what it means in reality is that the Following page may be incomplete and apparently unordered for a while. Once people reply to things it will reconstitute the state that drives it.

You're probably not going to notice... but in fixing the above issue with a SQL query that would take a long time to execute I've re-written it and it no longer takes 24h to run, it now takes about 3s to run.

As a result... I changed things so it runs every hour, and the side effect of that is that the Following page is now a lot quicker than it used to be and it should stay that way.

That's quite the optimisation!

Yeah, it's here:
https://github.com/microcosm-cc/microcosm/commit/1c22d43dd994abdf6a48c3715c5d87275e520978

Gist:

• You watch a conversation.
  
• Every new reply to something you're watching triggers a write to the updates table to say "someone has replied"... you may get a notification (based on the last thing you've read in the conversation, we don't spam you for each reply made only the first - this happens at the time of writing to the table)
  
• The Following page uses the last entry in the table to determine the things that you're watching that have been updated.
  
  

So... if 100 people are watching a conversation, and 100 replies are made... 10,000 rows just got created, but we only need the most recent 100, the most recent one for each person watching the conversation.

The job of the query then...

• Find all updates for a user for a user, and delete everything that isn't the latest.
  
  

The old query did it like this "find the latest updates as we want to keep those, use that to find all of the old updates as we want to lose those, delete the ones we want to lose":

WITH keep AS (
SELECT MAX(u.update_id) update_id
      ,u.for_profile_id
      ,u.parent_item_type_id
      ,u.parent_item_id
  FROM updates u
 WHERE u.update_type_id IN (1,4)
 GROUP BY u.for_profile_id
      ,u.parent_item_type_id
      ,u.parent_item_id
), lose AS (
    SELECT update_id
      FROM updates
     WHERE update_type_id IN (1,4)
       AND for_profile_id != 0
       AND parent_item_type_id != 0
       AND parent_item_id != 0
       AND update_id NOT IN (SELECT update_id FROM keep)
)
DELETE FROM updates
 WHERE update_id IN (SELECT * FROM lose);

But this is using a couple of sequential scans, and most importantly some very high cardinality JOINs, i.e. within the NOT IN. At a certain point we appear to have crossed some magic number and this query went from being really fast... to basically not completing. The JOINs introduced the problem.

The new query does it differently "find all updates except for the latest":

DELETE
  FROM updates
 WHERE update_id IN (
          -- All updates for an item
          SELECT update_id
            FROM updates
           WHERE update_type_id = 1
             AND parent_item_type_id > 0
          EXCEPT 
          -- Latest update for an item
          SELECT update_id
            FROM (
                    SELECT DISTINCT ON (for_profile_id, parent_item_type_id, parent_item_id) update_id
                      FROM updates
                     WHERE update_type_id = 1
                       AND parent_item_type_id > 0
                     ORDER BY for_profile_id, parent_item_type_id, parent_item_id, created DESC
                 ) AS latest
       );

This still has a sequential scan, but it no longer has a JOIN that forces an iteration. The UNION that underpins this does a hash compare.

I am reminded though, that I'm not sure I like SELECT DISTINCT ON let alone EXCEPT. They're powerful, but I always have to contort my thinking to remember precisely what they're doing. My natural habit is to reach for a SELECT GROUP BY HAVING which I did try but it didn't yield anything near the performance as it ran an additional aggregation step and sort which the DISTINCT ON didn't seem to do in the plans I looked at. My traditional approach only got it down to a few minutes, but the EXCEPT and DISTINCT ON got it down to seconds.

I did notice the improvement this morning, actually. Really good.