last seen tweet ID

[matthewberryman]

Hi @MaanasaPriyaa you mentioned a bug in this but I can't see what the issue is? I did a bit of testing and I can get a duplicate reply however that's only when I close down the database shortly after sending the message to the bot, due to a known timing issue where the tweet is processed but its ID not yet stored in the database. Tweets sent to the bot long enough before process termination (i.e. they are stored in the database) are ignored, and tweets sent while the bot is down only receive one reply as expected.

Note that the variable in the code is never updated after initially being set, as

• Tweet IDs are monotonically increasing, so it's sufficient to check > last seen tweet ID on load, and just keep the database UPDATEd.
• Updating the seen tweet ID is very problematic to do due to the asynchronous nature of JavaScript, i.e. you can end up with a race condition with one reply started before another has finished.

The small race condition identified above is very low priority as it's not often that we end up taking the bot down (typically once a month for kernel patches on the underlying instance).

Is there anything else you've noticed that seems odd?

[matthewberryman]

The other time this bit of code is used is if the connection to gnip-powertrack is lost—rare, and the last time that happened though was only because I restarted the process while Twitter's DNS servers were impacted by the mirai botnet.

[MaanasaPriyaa]

Got it. I had misinterpreted the flow wrt to last seen tweetId without the background knowledge. Glad to know it's working. I'll keep this bug open to fix the minor race condition down the line?

[matthewberryman]

Yes I think leave it open so we have that flagged on file.

[matthewberryman]

Took me a while to get my head around the flow, I initially went with gut instinct = keep it updated in the code, until I saw it cause a race condition and then realised we didn't need to :)