internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: zulip/zulip

Issue:
contrib_bots: Prevent runaway bots with rate limiting
It's possible to create a runaway bot if you have a bot send a message to certain stimuli that in turns becomes a stimulus for the bot to send another message and so on and so forth.

We can prevent that in `contrib_bots/run.py` by adding some logic to prevent runaway bots.

Right now RestrictedClient make self.send_message just be client.send_message, but we can instead have a wrapper like this:

```
def send_message(self, *args, **kwargs):
     self.rate_limit()
     self.client.send_message(*args, **kwargs)
```

And then have appropriate logic in `rate_limit()` and some state variable to make sure less than N messages have been sent in the last second.  It might make sense to have a small class for rate limiting that RestrictedClient uses an instance of.

You can do a pretty naive rate limiting scheme where you just keep the last N timestamps in a Python list and truncate it off the front as new sends come in and the list grows to size N+1.


Discussion:
Working on this :)

Resolving patch:
diff --git a/contrib_bots/run.py b/contrib_bots/run.py
--- a/contrib_bots/run.py
+++ b/contrib_bots/run.py
@@ -6,6 +6,7 @@
 import optparse
 import os
 import sys
+import time
 
 our_dir = os.path.dirname(os.path.abspath(__file__))
 
@@ -15,11 +16,27 @@
 
 from zulip import Client
 
+class RateLimit(object):
+    def __init__(self, message_limit, interval_limit):
+        self.message_limit = message_limit
+        self.interval_limit = interval_limit
+        self.message_list = []
+
+    def is_legal(self):
+        self.message_list.append(time.time())
+        if len(self.message_list) > self.message_limit:
+            self.message_list.pop(0)
+            time_diff = self.message_list[-1] - self.message_list[0]
+            return time_diff >= self.interval_limit
+        else:
+            return True
+
 class RestrictedClient(object):
     def __init__(self, client):
         # Only expose a subset of our Client's functionality
         user_profile = client.get_profile()
-        self.send_message = client.send_message
+        self.rate_limit = RateLimit(20, 5)
+        self.client = client
         try:
             self.full_name = user_profile['full_name']
             self.email = user_profile['email']
@@ -28,6 +45,15 @@ def __init__(self, client):
                           ' up the zuliprc file correctly.')
             sys.exit(1)
 
+    def send_message(self, *args, **kwargs):
+        if self.rate_limit.is_legal():
+            self.client.send_message(*args, **kwargs)
+        else:
+            logging.error('-----> !*!*!*MESSAGE RATE LIMIT REACHED, EXITING*!*!*! <-----\n'
+                  'Is your bot trapped in an infinite loop by reacting to'
+                  ' its own messages?')
+            sys.exit(1)
+
 def get_lib_module(lib_fn):
     lib_fn = os.path.abspath(lib_fn)
     if not os.path.dirname(lib_fn).startswith(os.path.join(our_dir, 'lib')):


Test patch:
Repository: zulip/zulip

Issue:
Followup Zulip API client `get_subscribers()`
See: https://chat.zulip.org/#narrow/near/125228/stream/backend/topic/Issue.20.231709

In Zulip API client, there is a function named `get_subscribers()`. This function has just been modified by a new commit that replace all `stream_name` with `stream_id` https://github.com/zulip/zulip/commit/d3ee53bdef75eb1fe6b71fb008c754b005a29ce2

And there is a exception, that's not handled correctly and hard to read.
```diff py
-        stream = urllib.parse.quote(request['stream'], safe='')
-        url = 'streams/%s/members' % (stream,)
+        request_stream_id = self.get_stream_id(request['stream'])
+        try:
+            stream_id = request_stream_id['stream_id']
+        except KeyError:
+            return request_stream_id
+        url = 'streams/%d/members' % (stream_id,)
```

Look at the `except KeyError:`, many developer will confused with that. The error handling here is not optimal, we could do something better than this..


Discussion:
Working on this..

Resolving patch:
diff --git a/api/zulip/__init__.py b/api/zulip/__init__.py
--- a/api/zulip/__init__.py
+++ b/api/zulip/__init__.py
@@ -659,11 +659,11 @@ def get_subscribers(self, **request):
         '''
             Example usage: client.get_subscribers(stream='devel')
         '''
-        request_stream_id = self.get_stream_id(request['stream'])
-        try:
-            stream_id = request_stream_id['stream_id']
-        except KeyError:
-            return request_stream_id
+        response = self.get_stream_id(request['stream'])
+        if response['result'] == 'error':
+            return response
+
+        stream_id = response['stream_id']
         url = 'streams/%d/members' % (stream_id,)
         return self.call_endpoint(
             url=url,


Test patch:
Repository: zulip/zulip

Issue:
Wikipedia bot crashes when the query contains multiple word delimit by underscore.
The bot is under `contrib_bots/bots`.  Some error handling is needed.


Discussion:
@tommyip I edited your description to have a bit more context for someone not familiar with what this is (just the path to the file).  It's good practice to include that sort of detail since it's generally fast to enter and can save a lot of time for someone picking up the project.
@tommyip could you give an example to what breaks the bot?
@lonerz 
Works:
`multiple word`

Crash:
`multiple_word`
Has this issue been solved 
When i tried to test it the wikipedia bot doesn't crash when the query contains multiple words separated by underscore

Resolving patch:
diff --git a/contrib_bots/bots/wikipedia/wikipedia.py b/contrib_bots/bots/wikipedia/wikipedia.py
--- a/contrib_bots/bots/wikipedia/wikipedia.py
+++ b/contrib_bots/bots/wikipedia/wikipedia.py
@@ -60,12 +60,12 @@ def handle_message(self, message, client, state_handler):
             logging.error('unsuccessful data')
             return
 
-        search_string = data.json()['query']['search'][0]['title'].replace(' ', '_')
-        url = 'https://wikipedia.org/wiki/' + search_string
         new_content = 'For search term "' + query
         if len(data.json()['query']['search']) == 0:
             new_content = 'I am sorry. The search term you provided is not found :slightly_frowning_face:'
         else:
+            search_string = data.json()['query']['search'][0]['title'].replace(' ', '_')
+            url = 'https://en.wikipedia.org/wiki/' + search_string
             new_content = new_content + '", ' + url
 
         client.send_message(dict(


Test patch:
Repository: zulip/zulip

Issue:
Enable enter to send in dev env
In dev environment every time we fresh login we have to check ```Enter to send``` to true. We should enable it by default for dev env only to increase testing speed.

```git grep enter_sends``` will help you.


Discussion:

Resolving patch:
diff --git a/zerver/lib/bulk_create.py b/zerver/lib/bulk_create.py
--- a/zerver/lib/bulk_create.py
+++ b/zerver/lib/bulk_create.py
@@ -21,7 +21,8 @@ def bulk_create_users(realm, users_raw, bot_type=None, tos_version=None):
         profile = create_user_profile(realm, email,
                                       initial_password(email), active, bot_type,
                                       full_name, short_name, None, False, tos_version,
-                                      tutorial_status=UserProfile.TUTORIAL_FINISHED)
+                                      tutorial_status=UserProfile.TUTORIAL_FINISHED,
+                                      enter_sends=True)
         profiles_to_create.append(profile)
     UserProfile.objects.bulk_create(profiles_to_create)
 
diff --git a/zerver/lib/create_user.py b/zerver/lib/create_user.py
--- a/zerver/lib/create_user.py
+++ b/zerver/lib/create_user.py
@@ -26,8 +26,9 @@ def random_api_key():
 # Recipient objects
 def create_user_profile(realm, email, password, active, bot_type, full_name,
                         short_name, bot_owner, is_mirror_dummy, tos_version,
-                        tutorial_status=UserProfile.TUTORIAL_WAITING):
-    # type: (Realm, Text, Optional[Text], bool, Optional[int], Text, Text, Optional[UserProfile], bool, Optional[Text], Optional[Text]) -> UserProfile
+                        tutorial_status=UserProfile.TUTORIAL_WAITING,
+                        enter_sends=False):
+    # type: (Realm, Text, Optional[Text], bool, Optional[int], Text, Text, Optional[UserProfile], bool, Optional[Text], Optional[Text], bool) -> UserProfile
     now = timezone.now()
     email = UserManager.normalize_email(email)
 
@@ -38,6 +39,7 @@ def create_user_profile(realm, email, password, active, bot_type, full_name,
                                bot_owner=bot_owner, is_mirror_dummy=is_mirror_dummy,
                                tos_version=tos_version,
                                tutorial_status=tutorial_status,
+                               enter_sends=enter_sends,
                                onboarding_steps=ujson.dumps([]),
                                default_language=realm.default_language)
 


Test patch:
Repository: zulip/zulip

Issue:
emails: Remove whitespace caused by jinja2 controls in non-HTML templates.
Jinja2 control tags like `{% name %}` add spaces and newlines to the body of plaintext emails. Jinja2 can be configured to strip this whitespace, and we should do so for our plaintext emails.

Some notes:
* This builds on #5248 (so if that hasn't been merged, work off of that branch)
* This is the diff to update the Jinja2 setting in `zproject/settings.py`:
```
non_html_template_engine_settings['OPTIONS'].update({
     'autoescape': False,
+    'trim_blocks': True,
+    'lstrip_blocks': True,
 })
```
You can read about the settings at http://jinja.pocoo.org/docs/2.9/templates/#whitespace-control
 * All of our emails templates live in `templates/zerver/emails`. The affected files are the ones that end in `*.subject` and `*.txt`.

The main task is to go through all the affected files, and make sure:
* All control tags are on their own lines
* Spot check a few of the emails in the development environment, to make sure the `trim_blocks` and `lstrip_blocks` setting is working as expected. 




Discussion:
Hello @zulip/server-notifications members, this issue was labeled with the **area: notifications** label, so you may want to check it out!
@zulipbot claim
So far, the problems regarding control blocks not being aligned are in:
* `digest.txt`, `missed_message.txt` :these will be redone so will leave them for now
* `invitation_reminder.subject` : currently figuring out how to verify it

Resolving patch:
diff --git a/zproject/settings.py b/zproject/settings.py
--- a/zproject/settings.py
+++ b/zproject/settings.py
@@ -335,6 +335,8 @@ def get_secret(key):
 })
 non_html_template_engine_settings['OPTIONS'].update({
     'autoescape': False,
+    'trim_blocks': True,
+    'lstrip_blocks': True,
 })
 
 # The order here is important; get_template and related/parent functions try


Test patch:
diff --git a/zerver/views/test_emails.py b/zerver/views/test_emails.py
--- a/zerver/views/test_emails.py
+++ b/zerver/views/test_emails.py
@@ -48,6 +48,7 @@ def email_page(request):
         },
         'referrer_name': 'Road Runner',
         'referrer_email': 'runner@acme.com',
+        'referrer_realm_name': 'Acme Corporation',
         'realm_uri': realm.uri,
         'server_uri': settings.SERVER_URI,
         'old_email': 'old_address@acme.com',
Repository: zulip/zulip

Issue:
Pull GCI docs into main Zulip repo.
Some of our assets, like git cheatsheets, currently live in the zulip-gci repo.  We should move them to the main Zulip repo and link from appropriate places.

cc @synicalsyntax @lonerz @tommyip 


Discussion:
(move or copy, as appropriate)
Hello @zulip/server-development members, this issue was labeled with the **area: documentation (developer)** label, so you may want to check it out!
I'd probably move and just update the links in zulip-gci to point to the new place.
@zulipbot claim

should these go in the `docs/` folder or is there someplace more appropriate?
Yeah, and probably under the `DEVELOPER TUTORIALS` section.
@tommyip is [this](http://zulip.readthedocs.io/en/latest/reading-list.html) what you are referring to?
I belive @tommyip talks about the whole *Developer tutorials* in the docs structure. This means that the docs you'll be moving from the GCI repo should have their own entries here, in `docs/index.rst`:

```rst
 74 .. _developer-tutorials:
 75 
 76 .. toctree::
 77    :maxdepth: 2
 78    :caption: Developer tutorials
 79 
 80    integration-guide
 81    webhook-walkthrough
 82    new-feature-tutorial
 83    writing-views
 84    life-of-a-request
 85    reading-list
```

So you should basically copy them as new files inside `docs/`, add the new files' names to the abovementioned list in `index.rst`, and update the links as @timabbott pointed out (in a separate PR in the zulip-gci repo).

Resolving patch:
diff --git a/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py b/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
--- a/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
+++ b/tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
@@ -17,6 +17,8 @@
     'https://calendar.google.com/calendar/embed?src=ktiduof4eoh47lmgcl2qunnc0o@group.calendar.google.com',
     # Returns 409 errors to HEAD requests frequently
     'https://medium.freecodecamp.com',
+    # Returns 404 to HEAD requests unconditionally
+    'https://www.git-tower.com/blog/command-line-cheat-sheet/',
 ]
 
 


Test patch:
Repository: zulip/zulip

Issue:
"Link to this conversation" with group pm conversations isn't shareable
If I have a conversation with alice@example.com and bob@example.com, and want to email them a permanent link to the conversation using the "Link to this conversation" feature, it doesn't work, because we generate a link of the form:

`/#narrow/near/12345/pm-with/alice.40example.2Ecom.2Cbob.40example.2Ecom`

which doesn't contain me!  We should probably change the structure so that those links contain oneself, the extra person of yourself just has no effect on the actual filter.


Discussion:
@timabbott  can i work on this? 
Update: Thanks to a bunch of refactoring to support email address changes, the `pm-with` narrow tokens now contain an opaque list of user IDs; so I think we could now just add yourself to the list of user IDs to make these shareable.  @showell does that approach makes sense to you?
Yep, without knowing the details too much, that approach makes sense to me.

We have a lot of code that deals with adding/removing yourself from the list of PM recipients--it would be nice to come up with a consistent philosophy on how to represent  PMs, but that's beyond the scope of this ticket.
@zulipbot claim

Resolving patch:
diff --git a/zerver/views/messages.py b/zerver/views/messages.py
--- a/zerver/views/messages.py
+++ b/zerver/views/messages.py
@@ -261,7 +261,8 @@ def by_pm_with(self, query, operand, maybe_negate):
         if ',' in operand:
             # Huddle
             try:
-                emails = [e.strip() for e in operand.split(',')]
+                # Ignore our own email if it is in this list
+                emails = [e.strip() for e in operand.split(',') if e.strip() != self.user_profile.email]
                 recipient = recipient_for_emails(emails, False,
                                                  self.user_profile, self.user_profile)
             except ValidationError:


Test patch:
diff --git a/frontend_tests/node_tests/filter.js b/frontend_tests/node_tests/filter.js
--- a/frontend_tests/node_tests/filter.js
+++ b/frontend_tests/node_tests/filter.js
@@ -310,6 +310,19 @@ function make_sub(name, stream_id) {
     }));
     assert(!predicate({type: 'stream'}));
 
+    predicate = get_predicate([['pm-with', 'Joe@example.com,steve@foo.com']]);
+    assert(predicate({
+        type: 'private',
+        display_recipient: [{user_id: joe.user_id}, {user_id: steve.user_id}],
+    }));
+
+    // Make sure your own email is ignored
+    predicate = get_predicate([['pm-with', 'Joe@example.com,steve@foo.com,me@example.com']]);
+    assert(predicate({
+        type: 'private',
+        display_recipient: [{user_id: joe.user_id}, {user_id: steve.user_id}],
+    }));
+
     predicate = get_predicate([['pm-with', 'nobody@example.com']]);
     assert(!predicate({
         type: 'private',
Repository: zulip/zulip

Issue:
Something is wrong with the default value for bot_type for bots
I appear to have some bots with no valid bot type on chat.zulip.org.

![image](https://user-images.githubusercontent.com/2746074/27241160-7c0284c6-528c-11e7-8861-3863959014f5.png)

I checked in the DB, and indeed the `bot_type` is None.  Seems to be common among very old bots.  So I think we need a migrate to set the `bot_type` of anything with `is_bot=True` and a `None` `bot_type` to `1` (the only bot type that existed until recently).


Discussion:
Hello @zulip/server-bots members, this issue was labeled with the **area: bots** label, so you may want to check it out!
@zulipbot claim

Resolving patch:
diff --git a/zerver/migrations/0085_fix_bots_with_none_bot_type.py b/zerver/migrations/0085_fix_bots_with_none_bot_type.py
new file mode 100644
--- /dev/null
+++ b/zerver/migrations/0085_fix_bots_with_none_bot_type.py
@@ -0,0 +1,25 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.2 on 2017-06-20 10:31
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+from django.db.backends.postgresql_psycopg2.schema import DatabaseSchemaEditor
+from django.db.migrations.state import StateApps
+
+def fix_bot_type(apps, schema_editor):
+    # type: (StateApps, DatabaseSchemaEditor) -> None
+    UserProfile = apps.get_model("zerver", "UserProfile")
+    bots = UserProfile.objects.filter(is_bot=True, bot_type=None)
+    for bot in bots:
+        bot.bot_type = 1
+        bot.save()
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('zerver', '0084_realmemoji_deactivated'),
+    ]
+
+    operations = [
+        migrations.RunPython(fix_bot_type),
+    ]


Test patch:
Repository: zulip/zulip

Issue:
docs: webpage titles for docs still say "Zulip 1.4.0 Documentation"
This is a bit out of date and appears as the title of webpages on the first page of Google search results for "Zulip." Screenshot attached. 
<img width="960" alt="screenshot 2017-06-20 12 17 43" src="https://user-images.githubusercontent.com/5571464/27344430-3d0db896-55b4-11e7-8d01-0be10492a759.png">



Discussion:
Hello @zulip/server-development members, this issue was labeled with the **area: documentation (developer)** label, so you may want to check it out!
@zulipbot claim

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -44,7 +44,7 @@
 
 # General information about the project.
 project = u'Zulip'
-copyright = u'2015-2016, The Zulip Team'
+copyright = u'2015-2017, The Zulip Team'
 author = u'The Zulip Team'
 
 # The version info for the project you're documenting, acts as replacement for
@@ -52,9 +52,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = '1.4'
+version = '1.6'
 # The full version, including alpha/beta/rc tags.
-release = '1.4.0'
+release = '1.6.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.


Test patch:
Repository: zulip/zulip

Issue:
Translated messages in Handlebars templates should never contain handlebars
When a Handlebars template contains something like this:
```
           {{#tr this}}Your email is {{ page_params.email }}.{{/tr}}
```
it results in the inside expression (`{{ page_params.email }}`) being evaluated and substituted *first*, and only then the result being looked up for translation. That's rarely going to work, and we should just never do it. The correct way to write this, documented in [our frontend i18n docs](http://zulip.readthedocs.io/en/latest/translating.html#frontend-translations), is with a `__`-marked variable to be substituted by `i18next` itself:
```
           {{#tr this}}Your email is __email__.{{/tr}}
```
(That or reword to separate the message from the variable, as say a label for a field; that'd be the right thing in this simple example.)

There are a handful of cases of this today. We should eliminate them and enforce with a linter that we don't make more.



Discussion:
@umairwaheed can you take this one?
Yeah. @zulipbot claim.

Resolving patch:
diff --git a/tools/linter_lib/custom_check.py b/tools/linter_lib/custom_check.py
--- a/tools/linter_lib/custom_check.py
+++ b/tools/linter_lib/custom_check.py
@@ -385,6 +385,12 @@ def custom_check_file(fn, rules, skip_rules=None, max_length=None):
          'description': "Period should be part of the translatable string."},
         {'pattern': "{{/tr}}[\.\?!]",
          'description': "Period should be part of the translatable string."},
+        {'pattern': "{{#tr.*}}.*{{.*{{/tr}}",
+         'exclude_line': set([
+             ('static/templates/subscription_settings.handlebars',
+              '{{#if subscribed }}{{#tr oneself }}Unsubscribe{{/tr}}{{else}}{{#tr oneself }}Subscribe{{/tr}}{{/if}}</button>'),
+         ]),
+         'description': "Translated messages should not contain handlebars."},
     ]
     jinja2_rules = html_rules + [
         {'pattern': "{% endtrans %}[\.\?!]",


Test patch:
diff --git a/frontend_tests/node_tests/templates.js b/frontend_tests/node_tests/templates.js
--- a/frontend_tests/node_tests/templates.js
+++ b/frontend_tests/node_tests/templates.js
@@ -635,6 +635,7 @@ function render(template_name, args) {
             content: 'This is message one.',
             last_edit_timestr: '11:00',
             starred: true,
+            starred_status: "Unstar",
         },
     };