@SurajRao On chat.SE, each chat room has a "host" site setting, which can be assigned to a specific SE site or to "The Stack Exchange Network" in general. Tag syntax on chat.SE only works in rooms which have a specific site set as the host, as the tags link specifically to the tags on that site. This room has the host set to "The Stack Exchange Network", so tag formatting doesn't work here. On chat.SO, there's no host setting and all rooms are associated with SO.
@SmokeDetector There was a crash here which appears related to problems with MS. We should look at it and resolve the issue, so a !!/ms-down command isn't required to be immediately issued.
### TypeError on Makyen/EC2-linux at 2021-11-24T17:18:03Z: object of type 'NoneType' has no len() File "ws.py", line 272, in <module> is_spam, reason, why = check_if_spam_json(a) File "/home/ec2-user/SmokeDetector/spamhandling.py", line 102, in check_if_spam_json is_spam, reason, why = check_if_spam(post) File "/home/ec2-user/SmokeDetector/spamhandling.py", line 48, in check_if_spam test, why = findspam.FindSpam.test_post(post) File "/home/ec2-user/SmokeDetector/findspam.py", line 592, in test_post
MS outage due to ISP outage - No ETA on a fix - WAS working with the ISP to solve this but all they're doing is jerking me around in a circle, from one support person to the next without ETA or anything. So at this point all I can say is "They'll fix it when they fix it". (I am online via my phone right now, but MS is not)
@tripleee There are a few things which try to fetch data from MS in order to run the detections. They should fail in a way which doesn't prevent processing.
@tripleee My understanding is those tests run the detections, so have all dependencies inherent in all detections, which does include making requests to MS for data.
this particular test suite just runs the regex and DNS tests, there should be no need to fetch anything from MS ... and indeed, commenting out my new code fixed the apparent freeze
@Machavity Hmmm... It looks like I should fix that. It should be written such that the FIRE button stops spinning immediately upon FIRE determining that it won't be able to open the popup.
The next significant update of FIRE is expected to include recognizing when MS is down and using data fetched from the SE API as an alternate method of displaying the post. Not including that feature (which is intertwined with a rewrite of how FIRE handles getting data) in the most recent release resulted in me forgetting to include stopping the button from spinning in the failure cases, although it will be caught by the general failure timeout.
[ SmokeDetector | MS |🔥] Phone number detected in title, potentially bad keyword in title (263): Meta.Smoke_SuPPort_Number (1-555+CALL-THOMAS)⇋☎️USA $N0V$ Meta.Smoke HeLPline NumBer by Sm0k3Dete(t0r on stackoverflow.com
My EC2-linux SD instance is a low-end AWS lightsail instance. As such, it's really only good for relatively brief backup use, due to limited CPU credits and AWS lightsail's inability to purchase more credits (which is ... unfortunate, IMO). The amount of time for which it can actually operate without CPU throttling, depends on how much CPU SD is taking.
Today, the CPU was pegged at 100% for the first 45+ minutes and then stayed high, which resulted in rapidly burning through the accumulated CPU credit. Overall, the first 1:05 hours burned through 80% of the available CPU credit, which had been accumulated over 24 hours of non-activity, well, actually, minimal activity, as the metasmoke relay instance is on this AWS lightsail too.
My EC2-num02 is an EC2 t3.small, which has twice the physical CPU capability and is set up to purchase CPU credits when/if needed. While I still need to experiment as to what's really needed, and that changes as we change SD, I expect the baseline vCPU credits from a t3.small, when averaged over AWS' 24 hour period, to be close to matching the CPU performance needed by a full-time SD instance.
With respect to CPU usage in this case, the startup appears to be similar to what I was seeing in the EC2-linux instance, which that CPU usage is at or near 100% for an extended time (sufficient such that an EC2 t3.small which wasn't started in unlimited CPU mode wouldn't have enough startup CPU credits).
That startup period does make it appear that the CPU credits provided by a t3.small are not enough, but I'll have to see what the average looks like over several/many hours. In any case, it will automatically just purchase more CPU credits, if needed.
Starting up the EC2-num02 instance is easy, as it's in a launch template that fully sets it up, but it's not currently automatic. I've been intending to set things up such that it runs as an AWS lambda in standby mode and then launches a new t3.small when moving to active mode, but I haven't gotten to that, yet.
[ SmokeDetector | MS ] Bad keyword in answer, bad keyword with email in answer, blacklisted website in answer, potentially bad keyword in answer (0): Invalid contact on hubspot by John on stackoverflow.com
@ThomasWard The difference between -force and not is that with -force SD won't decide that MS is up based on having succeeded in sending status pings. SD's going to try to send those pings, regardless of the state of -force. If it doesn't have -force, then nobody needs to A) notice that MS is up and B) remember to permit SD to be talking to MS once MS is up (by issuing !!/ms-up).
It seems like that's a good idea, unless MS is substantially unstable or stuck in a state where it will reply to pings, but not be able to perform other normal actions. So, I'm not really seeing a need for -force in this case. Or, at least, my expectation is that MS should be back up and running normally as soon as the internet connection is available again. Is my understanding of the state of MS incorrect? Is there something I'm not considering?
@ThomasWard Don't worry about it from the point of view of MS. These things happen from time to time. Obviously, it's a bit inconvenient for us, but the real concern, IMO, is the impact that it's having on you and the other things you do there.
MS outage due to ISP outage - No ETA on a fix - WAS working with the ISP to solve this but all they're doing is jerking me around in a circle, from one support person to the next without ETA or anything. So at this point all I can say is "They'll fix it when they fix it". (I am online via my phone right now, but MS is not)
