MS musings

quartata

Mar 30, 2017 14:56

I was thinking that if MS stores report chat IDs (which was going to be my new identifier for that) all an instance needed to do was ask MS for the last report

ArtOfCode

@quartata If you can figure out a way to send the report message ID to MS along with the report, then we can do that

quartata

That was my plan to replace by-post. It posts "Loading report..." first so it can observe the message ID then edits it

Then sends the ID off to MS

ArtOfCode

@quartata I'm gonna be a pain and say I'd rather we didn't do that either, because it'll mess with userscripts. Can we not just post the report, and send it to MS in a new thread launched from the message callback?

quartata

We could post it without the MS link and then edit it in. Userscripts should be able to handle that since MS links don't appear when MS is disabled

Or assuming MS ids are incremental and we're the only Smokey instance we could keep track of the next MS post id ourselves

ArtOfCode

Ideally, I'd like to not have to edit messages after they're posted

quartata

Mar 30, 2017 15:09

Soo... the latter then? We still need to send the chat ID to MS for commands but no editing is involved if we know the MS post ID

ArtOfCode

how about: send to MS, post the message at the same time, like we do already. When the message callback for the message we just posted fires, send another request to MS to update the post record (keyed by URL, because this is going to be sub-seconds after the report) with the message ID

quartata

And the MS link would be by chat ID?

ArtOfCode

hm

ArtOfCode

Mar 30, 2017 15:30

Hang on. @quartata what problem is this trying to solve? There might be a better way.

quartata

Mar 30, 2017 15:46

Right now Smokey is using /by-posts for both submitting feedback and the MS link, which is really problematic with different revisions. (Like, submitting feedback on different posts problematic)

The second is easily solvable just by giving MS the message ID.

ArtOfCode

Mar 30, 2017 15:57

Okay, so what if we made MS reject feedback on posts that have more than one record in the DB, and Smokey can tell people to use review?

quartata

That just seems like an unnecessary complication. There's no reason why they can't feedback from chat.

The real problem is just that post URL isn't a unique identifier of the state of a post at a given point in time, but we're treating it as one

ArtOfCode

@quartata it seems like less of a complication than either multiple HTTP requests for updating records on callbacks, or editing reports in, or editing parts of reports in... why not just "use review"#

quartata

I mean, we don't need to really submit multiple HTTP requests. If we're waiting for the report to be posted, then really we should just send the MS report afterwards.

The only difference is when it would hit the MS review queue.

And really then if we're waiting on the report and then doing MS, we should actually just do MS and then send the report

ArtOfCode

@quartata but then you have to edit the MS link in

quartata

@ArtOfCode Why would we? Right now there's no guarantees that the MS link works right away

The link couldn't be by chat ID if we post the report first without editing it either way

ArtOfCode

Mar 30, 2017 16:03

@quartata because if you're keying on message ID, then you don't have the message ID until the callback, when the message is already posted

and keying on MS ID might work most of the time but would probably break occasionally

quartata

We get the MS ID in MS's reply, right? We could edit it if it didn't match

Freak occasion so I don't feel bad about a weird edit

ArtOfCode

@quartata nope

We could, though

that might be an okay solution

quartata

We still need to send the message ID for commands though. I don't want to store a dictionary of message IDs to MS IDs or anything.

ArtOfCode

@quartata send the message ID where?

quartata

To MS.

ArtOfCode

Mar 30, 2017 16:05

uh

why?

quartata

OK, so when you do @command(reply=True) the message ID gets passed to the function

My intent with that was then for the feedback commands we could just do POST /posts/by-message/<id> or something

ArtOfCode

Yeah, that should just stay local if we're keying on MS ID

quartata

But then we can't submit feedback to old posts. That seems like an unnecessary limitation.

ArtOfCode

@quartata if we're keying on ID, why can't we use the ID instead of the message ID

quartata

We could parse the MS link out of the message I suppose.

@ArtOfCode Because we're not guaranteed to have it

ArtOfCode

Mar 30, 2017 16:07

@quartata Huh? We definitely have it, since we put it in the report message.

quartata

And if we restarted since then?

ArtOfCode

pickle on disk

quartata

So a pickle of every Smokey report ever? We have a name for that, it's called MS.

ArtOfCode

...what

quartata

And it's a lot more memory efficient than a pickled dictionary.

ArtOfCode

Mar 30, 2017 16:10

So. I send a feedback command. Smokey needs to issue POST https://metasmoke.erwaysoftware.com/feedback.json?id=54321. We know the report message ID, because I replied to it. Look that message ID up in a dictionary of message IDs => MS IDs, and send the HTTP request.

quartata

Right. So either we keep a massive dictionary locally that should really just be on MS, or we can't send feedback to old posts.

In a particularly bad spam o' clock I can see us reporting 100 posts.

ArtOfCode

@quartata over what timeframe?

We average 11/hr at the worst.

quartata

I was thinking 5-6 hours

But I'm not terribly good at counting. I let MS do that for me

Here let me check

ArtOfCode

I really don't think anyone actually replies to reports that old; they've all got feedback already

quartata

It just seems like a really arbitrary limitation.

And it's one that the current Smokey doesn't have, even if it has other issues with by-posts.

ArtOfCode

Mar 30, 2017 16:14

yes it does, it only keeps 100 message ids

quartata

OK, looks like the worst is about 20/hour. So I could see a post from 5 hours ago getting a different feedback (maybe an naa- getting a tpu- by say Yvette)

@ArtOfCode For straight up regular replies?

That's just weird. It doesn't need anything saved for that.

Oh wait yes it does...

It could get the post URL from the message though

ArtOfCode

So the alternative is another HTTP request to metasmoke in the message callback, keyed by ID (so we still need that dictionary but could delete from it quickly), to update the post record with the message ID

which... wouldn't be terrible, I guess

quartata

Maybe that's the best solution. Maintain a cache of message ID -> MS IDs, and if we get a miss just parse the message

ArtOfCode

long as it's threaded

quartata

@ArtOfCode Hmmm

ArtOfCode

Mar 30, 2017 16:17

@quartata that'd be okay, actually. And then we can key things like feedback on message ID.

quartata

Also why.

And !!/test-msg

ArtOfCode

@quartata that's kept locally

keep why data for the last 50 reports

quartata

I was going to make it so that if Smokey didn't have it locally it would ask MS

Although I was tempted to make it not keep it locally at all (assuming MS is up)

ArtOfCode

@quartata keep the most recent locally, because those get asked for fairly regularly so it's unnecessary load on MS. But yeah, beyond that

Say keep 20 and ask MS beyond that

quartata

That works.

We could save it after being asked and prune occassionally as well

ArtOfCode

Mar 30, 2017 16:20

potentially, but once it's been asked it probably won't get asked again soon

quartata

Unless someone's asking it maliciously. Not like that would work as a DOS since chat is ratelimited...

ArtOfCode

Yeah, we can pretty much rule out malicious actors in the system

♦ Beep Boop Bingus Bin

Participants