search

Charcoal-SE / SmokeDetector-ng

SmokeDetector reboot project.
Apache License 2.0
6 stars 3 forks source link

Metasmoke (Metasmoke-side, storing message IDs) #7

Closed quartata closed 7 years ago

Undo1 commented 7 years ago

Could you explain why this is necessary? (Why didn't we need to do this before?)

quartata commented 7 years ago

@Undo1 http://chat.stackexchange.com/rooms/30332/conversation/ms-musings

ArtOfCode- commented 7 years ago

We may as well have the discussion here. @Undo1 so because we key requests to MS on post URL at the moment (including sending feedback, not just the MS link), we can run into situations where the wrong post is on the end of the MS request (feedback gets assigned to the wrong revision of a post, for example). If we can store message IDs (and we'd have to store the chat host as well) on MS and key requests to MS on that, we eliminate that problem.

Undo1 commented 7 years ago

Would it be easier to make the metasmoke request synchronous and just use the native ID? Seems like it'd be a good tradeoff to make one synchronous request and handle it gracefully if it fails, rather than mess with storing/retrieving multiple chat IDs across three hosts.

ArtOfCode- commented 7 years ago

That would be significantly easier, it's just a matter of tuning timeouts so that we don't hang on the request for ever.

quartata commented 7 years ago

But as we already dscussed, that doesn't help with commands.

Undo1 commented 7 years ago

How so? The metasmoke ID would be in the message, and it'd be easy to store it locally in relation to message IDs.

quartata commented 7 years ago

We reached the conclusion that maintaining a dictionary like that (like we do now for last 100 message ID -> MS post url) results in a fairly arbitrary and potentially harmful limitation on how far back posts can have feedback submitted on or queried for why data. I can see people wanting to run a commandor submit feedback on a post 5 hours back, which on a bad day (20 reports/hour) could be too far back. And parsing the ID out if the message would be a nuisance.

quartata commented 7 years ago

I also think you're overestimating the impact of the different chat hosts Just append an s for SE, o for SO and m for MSE. Only the Smokey side would have to worry about processing the ID for MS, at any rate.

ArtOfCode- commented 7 years ago

I'll contest that it's harmful, since we already do it and see no ill effects from it. Could be improved, yes, but not harmful.

Realistically, if we want to move away from post URLs, something has to do extra processing somewhere. That could be Smokey, using a message -> MS lookup table, or it could be metasmoke, doing string processing and more database queries.

And now I put it like that, the lookup table sounds more efficient.