jimmycuadra / lita-karma Goto Github PK

From an issue reported by @iamleeg in our Lita's repo:

Jon W.: and true, currywurst is a Berlin thing. Weißwurst++
Nerdbot wurst: 1
Jon W.: späztle++
Nerdbot ztle: 1

Add a mutex around each command's operations to prevent any data races when commands are being processed concurrently.

The shell adapter should gracefully handle ctrl-D.

Commit to a public API for other Ruby code to perform all the same karma operations exposed through the chat interface.

If I type @name++ and @name2++ they both get karma, if I copy and paste @name++ @name2++ only name2 gets karma. If I paste @name++ followed by text, @name gets karma, so it's not an end of line issue. This is using the default config.

In examining the data dumped from my test Redis DB from both before and after I upgraded, I noticed that some modified:<term> keys were still plain SETs, not ZSETs.

This appears to have happened because there are modified:<term> keys for which there is no entry in the terms hash, and the keys of that hash are used to upgrade the modified:<term> SETs.

I don’t know how this might have happened in the course of normal operation, but if one of those terms was modified at a later date, I suspect Bad Things™ would occur.

Even though it is a performance drain, I think the safest option would be to get a list of modified:<term> keys and upgrade them, instead of relying on the list of terms being complete.

When a user is referenced in a Slack message, it comes through in the body as <@uniqueid>. This causes lita-karma to work inconsistently on Slack.

Obviously, this can be fixed with a custom term_pattern to match it and a custom term_normalizer to look up the user. But I think the defaults should probably handle this case because it breaks the principle of least astonishment.

I’m going to dig into fixing it now.

Not sure if this can be done, but we have a user who figured out that they can directly message the bot "in secret" and game the karma system.

I think it would be a change in https://github.com/jimmycuadra/lita-karma/blob/master/lib/lita/handlers/karma/chat.rb#L95-L127 - but I don't know that there's a semantic of restrict_to for direct messages, or something like that.

The shell adapter should have nice colors to help distinguish what the user is saying from what the bot is saying.

@erikogan

After running this plugin on master for a while on a personal Lita instance, some data loss was incurred. Many terms were deleted completely that had quite a lot of karma. I'm not quite sure I see the pattern/commonality in the terms that were deleted, but terms with negative karma don't seem to have been affected.

I'm thinking about reverting the karma decay features, as I don't want to risk anyone using master and losing data. It might be more complex of a feature than it's worth, in the end. I thought I'd give you a heads up in case you want to look at it though.

For reference, the commit I'm running that had this problem is fd89aed.

Hi there! I'm looking at tweaking some behavior, and wanted to write test cases. But, something is amiss. Most of the tests fail, because the command is executed twice. Digging a bit, I see the routes are generated twice.

I suspect something has changed in the last 11 months since your travis run, because if I just fork this, travis produces the same errors for me, as I get on my local host.

Though I did need to update travis to work around a bug. directionless@0b19d2e4c is the commit that does so.

https://travis-ci.org/directionless/lita-karma/builds/108911896 is my fork's failure. I don't think anything I did should cause that, and I suspect you'll see the same thing. directionless@6983d3f is a simple rspec file