What happened to Vivaldi Social?
thomasp.vivaldi.net
What happened to Vivaldi Social?
1–10 of 83 posts
Re: What happened to Vivaldi Social?
#2One of the better post-mortems I've read in a long while.
Re: What happened to Vivaldi Social?
#3Items two and three not happening atomically feels like an issue, though I assume there's a reason that it's not trivial to do so (I haven't looked at the code; really should at some point.)
Re: What happened to Vivaldi Social?
#4Bad luck on timing? Feels like luck had little to do with it and migration testing wasn't fuzz'd enough?
Re: What happened to Vivaldi Social?
#5This make anyone elses eyebrows raise sky high at this?
> Claire replied, asking for the full stacktraces for the log entries, which I was able to also extract from the logs.
This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286. House is that not, like, megabytes on every single hit?
Re: What happened to Vivaldi Social?
#6This make anyone elses eyebrows raise sky high at this? > Claire replied, asking for the full stacktraces for the log entries, which I was able to also extract from the logs. This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286. House is that not, like, megabytes on every single hit?
Recording stacktraces of errors is a pretty reasonable thing to do. And ideally not every hit causes an error.
Re: What happened to Vivaldi Social?
#7This make anyone elses eyebrows raise sky high at this? > Claire replied, asking for the full stacktraces for the log entries, which I was able to also extract from the logs. This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286. House is that not, like, megabytes on every single hit?
> HTTP 500 errors when viewing an account
> Stacktrace for that 500
This is the default ruby on rails behavior. It prints a stacktrace on any 500 or unknown error, and it's just line numbers and filepaths.
> megabytes on every single hit
I run a rails app that's very poorly designed.
I just checked, and the stack trace for a single 500 is 5KiB. It doesn't even add up to 1MiB a day since there's only a 500 error about every hour.
> This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286
Having a call stack handy is is actually pretty performant. Java's default exception behavior is to bubble up a stack trace with every exception, whether you print it or not, and java applications run just fine. You have the call stack anyway since you have to know how to return, so the only extra information you need handy is the filename and line number debug symbols, and ruby needs that info anyway just by the nature of the language.
Re: What happened to Vivaldi Social?
#8Hm, so a distributed twitter runs into the challenge that each independently managed node is ... and independently managed node. Backup problems etc.
Centralized twitter improves its operations for all users over time. But can be purchased by a nutso billionaire on a whim, or subjected to the """"""national security"""""" directives of the US Government.
Re: What happened to Vivaldi Social?
#9Hm, so a distributed twitter runs into the challenge that each independently managed node is ... and independently managed node. Backup problems etc. Centralized twitter improves its operations for all users over time. But can be purchased by a nutso billionaire on a whim, or subjected to the """"""national security"""""" directives of the US Government.
Perhaps better is decentralized twitter (Nostr). Your account doesn't live on a server and you send events to multiple servers if you want to. If one server goes down, it hardly impacts you.
Re: What happened to Vivaldi Social?
#10Items two and three not happening atomically feels like an issue, though I assume there's a reason that it's not trivial to do so (I haven't looked at the code; really should at some point.)
One of the linked fixes is: https://github.com/mastodon/mastodon/commit/13ec425b721c9594...
It seems like it was trivial to make it happen atomically.
There just wasn't a need to before since them not being atomic isn't an issue, unless you have a poor configuration like someone pointing sidekiq at a stale database server (sorry, a replica), which I see as the primary issue here.