kgess-mirror/matrix.org
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix.org.git synced 2026-01-11 20:07:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Migrate jira archive

Browse source
This commit is contained in:
Laurence Gill 2023-06-21 12:41:38 +01:00
parent 86b9961135
commit b0927d49e6
No known key found for this signature in database
2347 changed files with 96930 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
static/_headers
View file

@ -16,3 +16,7 @@
# Allow ACAO for well-known client
/.well-known/matrix/client
Access-Control-Allow-Origin: *
# Add content type for jira archive
/jira/browse/*
Content-Type: text/plain

22
static/jira/browse/BOTS-1 Normal file
View file

@ -0,0 +1,22 @@
---
summary: IRC Bridge isn't UTF-8 safe
---
created: 2014-09-30 13:55:54.0
creator: matthew
description: ''
id: '10423'
key: BOTS-1
number: '1'
priority: '2'
project: '10101'
reporter: matthew
resolution: '5'
resolutiondate: 2015-02-03 18:14:32.0
status: '5'
type: '1'
updated: 2015-02-03 18:14:32.0
votes: '0'
watches: '1'
workflowId: '10526'
---
actions: null

30
static/jira/browse/BOTS-10 Normal file
View file

@ -0,0 +1,30 @@
---
summary: IRC namespace collisions
---
created: 2014-11-18 09:14:56.0
creator: kegan
description: ''
id: '10667'
key: BOTS-10
number: '10'
priority: '2'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2015-07-28 14:05:40.0
status: '5'
type: '1'
updated: 2015-07-28 14:05:40.0
votes: '0'
watches: '1'
workflowId: '10767'
---
actions:
- author: kegan
body: Fixed with ASes.
created: 2015-07-28 14:05:40.0
id: '12033'
issue: '10667'
type: comment
updateauthor: kegan
updated: 2015-07-28 14:05:40.0

39
static/jira/browse/BOTS-100 Normal file
View file

@ -0,0 +1,39 @@
---
summary: we should bridge OFTC.net IRC
---
created: 2015-09-04 15:11:31.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11853'
key: BOTS-100
number: '100'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-26 09:48:38.0
votes: '0'
watches: '3'
workflowId: '11956'
---
actions:
- author: davidar
body: |-
This would be great. Relevant contact details can be found at http://www.oftc.net/staff/
I can try to get into contact with someone at OFTC if that would help?
created: 2015-09-12 09:55:26.0
id: '12130'
issue: '11853'
type: comment
updateauthor: davidar
updated: 2015-09-12 09:55:26.0
- author: matthew
body: Feedback is that as long as we use a different ipv6 source IP for each connection they're fine with us connecting. will open a bug for that.
created: 2015-09-19 23:37:59.0
id: '12146'
issue: '11853'
type: comment
updateauthor: matthew
updated: 2015-09-19 23:37:59.0

33
static/jira/browse/BOTS-101 Normal file
View file

@ -0,0 +1,33 @@
---
summary: the fact ASes retry all events during a HS outage can mean they DoS the HS on return
---
assignee: illicitonion
created: 2015-09-05 00:46:45.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
...and generally cause a weird UX as events trickle in slowly from the AS after said outage
id: '11854'
key: BOTS-101
number: '101'
priority: '3'
project: '10101'
reporter: neb
resolution: '2'
resolutiondate: 2016-01-04 17:04:57.0
status: '5'
type: '1'
updated: 2016-01-04 17:04:57.0
votes: '0'
watches: '2'
workflowId: '11957'
---
actions:
- author: illicitonion
body: This is a scalability issue of Synapse, and not a desired feature of ASes. We should fix Synapse/Dendron, not paper over it by crippling ASes.
created: 2016-01-04 17:04:57.0
id: '12497'
issue: '11854'
type: comment
updateauthor: illicitonion
updated: 2016-01-04 17:04:57.0

30
static/jira/browse/BOTS-102 Normal file
View file

@ -0,0 +1,30 @@
---
summary: Add github issue submission to NEB
---
created: 2015-09-05 14:31:18.0
creator: neb
description: Submitted by @kegan:matrix.org
id: '11856'
key: BOTS-102
number: '102'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-09-07 10:14:07.0
status: '5'
type: '1'
updated: 2015-09-07 10:14:07.0
votes: '0'
watches: '2'
workflowId: '11959'
---
actions:
- author: kegan
body: https://github.com/Kegsay/Matrix-NEB/commit/5b45aebc123ae84fb47a37a367a7de797deeb6b4
created: 2015-09-07 10:14:07.0
id: '12112'
issue: '11856'
type: comment
updateauthor: kegan
updated: 2015-09-07 10:14:07.0

22
static/jira/browse/BOTS-103 Normal file
View file

@ -0,0 +1,22 @@
---
summary: We really need to feedback errors etc when the IRC bridge can't join channels
---
created: 2015-09-07 00:58:37.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11859'
key: BOTS-103
number: '103'
priority: '1'
project: '10101'
reporter: neb
resolution: '3'
resolutiondate: 2016-01-04 15:16:10.0
status: '5'
type: '1'
updated: 2016-01-04 15:16:10.0
votes: '0'
watches: '1'
workflowId: '11962'
---
actions: null

30
static/jira/browse/BOTS-104 Normal file
View file

@ -0,0 +1,30 @@
---
summary: We should send images/files to IRC as messages, not notices. Some folks get really upset by notices in channels, as they appear like PMs.
---
created: 2015-09-13 02:56:38.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11869'
key: BOTS-104
number: '104'
priority: '1'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-09-14 10:00:22.0
status: '5'
type: '1'
updated: 2015-09-14 10:00:22.0
votes: '0'
watches: '1'
workflowId: '11972'
---
actions:
- author: neb
body: 'By @matthew:matrix.org: This is a regression effectively that started with the demise of MatrixBridge in commit 7b502fc3 on Tue Aug 11 10:23:16 2015'
created: 2015-09-13 02:57:31.0
id: '12131'
issue: '11869'
type: comment
updateauthor: neb
updated: 2015-09-13 02:57:31.0

22
static/jira/browse/BOTS-105 Normal file
View file

@ -0,0 +1,22 @@
---
summary: We need a way to resolve 3rd party room and users to an appropriate bridge
---
created: 2015-09-13 13:54:36.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
It's nuts to expect normal users to know the #network_#channel:matrix.org style syntax; instead we should have a way to ask a given HS what its default recommendation for resolving a remote room or user to an AS would be.
id: '11870'
key: BOTS-105
number: '105'
priority: '2'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2015-09-13 13:54:36.0
votes: '0'
watches: '1'
workflowId: '11973'
---
actions: null

22
static/jira/browse/BOTS-106 Normal file
View file

@ -0,0 +1,22 @@
---
summary: We need semantics for bridging public room discovery, user discovery, rosters, and similar concepts
---
created: 2015-09-16 10:05:34.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
How do we expose the Skype user directory to Matrix? How do we expose an XMPP roster to Matrix (if bridging at c2s)? How do we expose an IRC /list to Matrix?
id: '11880'
key: BOTS-106
number: '106'
priority: '2'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-04 15:38:50.0
votes: '0'
watches: '1'
workflowId: '11983'
---
actions: null

33
static/jira/browse/BOTS-107 Normal file
View file

@ -0,0 +1,33 @@
---
summary: 'IRC AS: Handle external entities'
---
created: 2015-09-17 17:05:33.0
creator: kegan
description: |-
If you have Github set up to splat commits into an IRC channel, it's done by using bot users which never join the channel specified, but emit notices instead. The IRC AS treats this as a real user, provisions an account and sends a message from that bot user, but never parts it again, leading to lots and lots of {{GitHub123456789}} users on the Matrix side.
We need to think of how we can gracefully do this, possibly by sending the messages from the AS itself? {{@appservice-irc:domain.com}}
id: '11881'
key: BOTS-107
number: '107'
priority: '2'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-06-02 10:19:57.0
status: '5'
type: '1'
updated: 2016-06-02 10:19:57.0
votes: '0'
watches: '1'
workflowId: '11984'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/42
created: 2016-06-02 10:19:57.0
id: '12948'
issue: '11881'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:19:57.0

22
static/jira/browse/BOTS-108 Normal file
View file

@ -0,0 +1,22 @@
---
summary: clarify matrix appservice node usage in the readme
---
created: 2015-09-18 18:24:50.0
creator: neb
description: Submitted by @kegan:matrix.org
id: '11886'
key: BOTS-108
number: '108'
priority: '1'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-09-24 10:53:47.0
status: '5'
type: '1'
updated: 2015-09-24 10:53:47.0
votes: '0'
watches: '1'
workflowId: '11989'
---
actions: null

30
static/jira/browse/BOTS-109 Normal file
View file

@ -0,0 +1,30 @@
---
summary: Need a way to tell Matrix users when an IRC user they are PMing has disconnected
---
created: 2015-09-18 22:05:12.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11887'
key: BOTS-109
number: '109'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:21:04.0
status: '5'
type: '1'
updated: 2016-06-02 10:21:04.0
votes: '0'
watches: '2'
workflowId: '11990'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/43
created: 2016-06-02 10:21:04.0
id: '12949'
issue: '11887'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:21:04.0

44
static/jira/browse/BOTS-11 Normal file
View file

@ -0,0 +1,44 @@
---
summary: Slack bridge
---
created: 2014-12-02 14:34:22.0
creator: matthew
description: |-
It'd probably make sense to build a slack<->matrix bridge just like the IRC one, as slack is getting increasing penetration and we'd like to obviously let it play nice with Matrix.
Reuqest comes from James at Truphone, plus I suspect Amandine would secretly like one too.
id: '10752'
key: BOTS-11
number: '11'
priority: '2'
project: '10101'
reporter: matthew
resolution: '1'
resolutiondate: 2015-09-17 16:59:39.0
status: '5'
type: '2'
updated: 2015-09-17 16:59:39.0
votes: '0'
watches: '3'
workflowId: '10852'
---
actions:
- author: leonerd
body: The way my er-rewrite branch of the IRC bridge now works means that IRC and Matrix are just two plugins into a shared "message bus" inbetween. If we write a slack plugin for that, then instantly we get any combination of up-to 3-way bridging if required.
created: 2015-02-03 18:12:52.0
id: '11216'
issue: '10752'
type: comment
updateauthor: leonerd
updated: 2015-02-03 18:12:52.0
- author: kegan
body: |-
This is now A Thing.
https://github.com/matrix-org/matrix-appservice-slack
created: 2015-09-17 16:59:39.0
id: '12135'
issue: '10752'
type: comment
updateauthor: kegan
updated: 2015-09-17 16:59:39.0

109
static/jira/browse/BOTS-110 Normal file
View file

@ -0,0 +1,109 @@
---
summary: 'Unable to join Freenode channel #ft_kickass'
---
assignee: kegan
created: 2015-09-19 00:00:00.0
creator: rrix
description: ''
id: '11888'
key: BOTS-110
number: '110'
priority: '2'
project: '10101'
reporter: rrix
resolution: '1'
resolutiondate: 2016-06-22 16:03:53.0
status: '5'
type: '1'
updated: 2016-06-22 16:03:53.0
votes: '0'
watches: '3'
workflowId: '11991'
---
actions:
- author: kegan
body: This channel has {{+S}} set (SSL only) which we currently don't do because of BOTS-51 - when this bug is resolved it should Just Work.
created: 2015-09-24 09:33:15.0
id: '12163'
issue: '11888'
type: comment
updateauthor: kegan
updated: 2015-09-24 09:33:15.0
- author: matthew
body: |-
Ryan removed the +S (the room is now just +ns) and still broken. I see no attempts to join the room at all, though, so i think the problem is that the bridge's DB has corrupt state left over from previous attempts:
$ cat rooms.db | grep -i kickass
{"room_id":"!QRsXmHRKrxahKgCCxb:matrix.org","irc_addr":"irc.freenode.net","irc_chan":"#ft_kickass","from_config":false,"type":"channel","_id":"Lub0DPfRN7NxCc1g"}
{"room_id":"!QRsXmHRKrxahKgCCxb:matrix.org","irc_addr":"irc.freenode.net","irc_chan":"#ft_kickass","from_config":false,"type":"channel","_id":"MeQghpmcDXbKekuU"}
{"room_id":"!QRsXmHRKrxahKgCCxb:matrix.org","irc_addr":"irc.freenode.net","irc_chan":"#ft_kickass","from_config":false,"type":"channel","_id":"Rqeapm800RozcHDF"}
{"room_id":"!QRsXmHRKrxahKgCCxb:matrix.org","irc_addr":"irc.freenode.net","irc_chan":"#ft_kickass","from_config":false,"type":"channel","_id":"ZghhNsJPIcj6SFRC"}
...looks deeply wrong; surely there should only be 1 entry?
created: 2015-11-15 00:57:10.0
id: '12363'
issue: '11888'
type: comment
updateauthor: matthew
updated: 2015-11-15 00:57:10.0
- author: kegan
body: The db file you're grepping is an append-only log. You'd need to make sure these entries aren't being deleted; a simple grep isn't sufficient. It sounds plausible that the room the bridge is trying to use is a bit screwy.
created: 2015-11-16 10:22:10.0
id: '12364'
issue: '11888'
type: comment
updateauthor: kegan
updated: 2015-11-16 10:22:10.0
- author: rrix
body: '*gently nudges* Is it possible to remove those rooms from the AOL?'
created: 2015-12-07 15:53:02.0
id: '12440'
issue: '11888'
type: comment
updateauthor: rrix
updated: 2015-12-07 15:53:02.0
- author: kegan
body: |-
I can nuke them from the db yes. What would be the purpose of doing this?
EDIT: *regains context* - Right, yes, I can do that.
created: 2015-12-08 09:38:21.0
id: '12443'
issue: '11888'
type: comment
updateauthor: kegan
updated: 2015-12-08 09:39:45.0
- author: kegan
body: What is the current failure mode if you try to join {{#freenode_#ft_kickass:matrix.org}} ?
created: 2015-12-08 09:43:59.0
id: '12444'
issue: '11888'
type: comment
updateauthor: kegan
updated: 2015-12-08 09:43:59.0
- author: rrix
body: |-
Just an M_UNKNOWN 403
{"errcode":"M_UNKNOWN","error":"Forbidden"}
created: 2015-12-10 05:34:15.0
id: '12455'
issue: '11888'
type: comment
updateauthor: rrix
updated: 2015-12-10 05:34:15.0
- author: kegan
body: Was this ever resolved?
created: 2016-06-02 10:21:58.0
id: '12950'
issue: '11888'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:21:58.0
- author: kegan
body: 'bq. Kegan: yeah, not the SSL issue but the weird database state was resolved at some point'
created: 2016-06-22 16:03:53.0
id: '13015'
issue: '11888'
type: comment
updateauthor: kegan
updated: 2016-06-22 16:03:53.0

38
static/jira/browse/BOTS-111 Normal file
View file

@ -0,0 +1,38 @@
---
summary: users without webcams can't join VCs via verto
---
created: 2015-09-19 16:02:37.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11891'
key: BOTS-111
number: '111'
priority: '2'
project: '10101'
reporter: neb
resolution: '4'
resolutiondate: 2015-09-24 09:18:36.0
status: '5'
type: '1'
updated: 2015-09-24 09:18:36.0
votes: '0'
watches: '2'
workflowId: '11994'
---
actions:
- author: kegan
body: This is a client-side problem. This is not specific to the Verto AS.
created: 2015-09-24 09:16:51.0
id: '12161'
issue: '11891'
type: comment
updateauthor: kegan
updated: 2015-09-24 09:16:51.0
- author: kegan
body: https://github.com/vector-im/vector-web/issues/188
created: 2015-09-24 09:18:36.0
id: '12162'
issue: '11891'
type: comment
updateauthor: kegan
updated: 2015-09-24 09:18:36.0

20
static/jira/browse/BOTS-112 Normal file
View file

@ -0,0 +1,20 @@
---
summary: NEB's !github fails if args include non-ASCII UTF8
---
created: 2015-09-19 16:06:01.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11893'
key: BOTS-112
number: '112'
priority: '2'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2015-09-19 16:06:01.0
votes: '0'
watches: '1'
workflowId: '11996'
---
actions: null

32
static/jira/browse/BOTS-113 Normal file
View file

@ -0,0 +1,32 @@
---
summary: Support for ipv6 source addresses on IRC bridge
---
created: 2015-09-19 23:38:33.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
BOTS-100 and similar require us to connect via IPv6, with a different source addy for each connection
id: '11899'
key: BOTS-113
number: '113'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:13:39.0
status: '5'
type: '1'
updated: 2016-06-02 10:13:39.0
votes: '0'
watches: '2'
workflowId: '12002'
---
actions:
- author: kegan
body: Experimental support (untested since our DC doesn't do v6) is now done.
created: 2016-06-02 10:13:39.0
id: '12944'
issue: '11899'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:13:39.0

22
static/jira/browse/BOTS-114 Normal file
View file

@ -0,0 +1,22 @@
---
summary: matrix-appservice-purple needs to exist
---
created: 2015-09-20 00:50:27.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
I resurrected node-purple; someone needs to wire it into a matrix-appservice-bridge to finish off bridging Lync and friends
id: '11901'
key: BOTS-114
number: '114'
priority: '2'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2015-09-20 00:50:27.0
votes: '1'
watches: '2'
workflowId: '12004'
---
actions: null

21
static/jira/browse/BOTS-115 Normal file
View file

@ -0,0 +1,21 @@
---
summary: matrix-appservice-bridge intent.sendMessage messes with send ordering
---
assignee: kegan
created: 2015-09-21 11:23:46.0
creator: illicitonion
description: ''
id: '11904'
key: BOTS-115
number: '115'
priority: '2'
project: '10101'
reporter: illicitonion
status: '1'
type: '1'
updated: 2015-09-21 11:23:46.0
votes: '0'
watches: '1'
workflowId: '12007'
---
actions: null

40
static/jira/browse/BOTS-116 Normal file
View file

@ -0,0 +1,40 @@
---
summary: '" (IRC)" attached to usernames when mentioning others in IRC'
---
created: 2015-09-22 20:00:02.0
creator: chreekat
description: |-
Sorry if I'm doing this wrong; never used JIRA before.
A matrix user joined us in #snowdrift on Freenode, which is cool. When that person mentions others in the channel, however, " (IRC)" is appended to their name, e.g.,
> chreekat (IRC): will wait for the merge.
That is distracting to all of us who are actually in the channel. We already know the user is talking to someone on IRC. :)
id: '11911'
key: BOTS-116
number: '116'
priority: '2'
project: '10101'
reporter: chreekat
status: '1'
type: '1'
updated: 2016-01-26 09:48:41.0
votes: '0'
watches: '2'
workflowId: '12014'
---
actions:
- author: matthew
body: |-
Hi Bryan - thanks for the bug report; sorry about this. It's already been filed as https://github.com/vector-im/vector-web/issues/99 and SYWEB-332. However, fixing this properly would be to identify users in Matrix in a group based on the network they're bridged from - which is SPEC-107.
In the short term, we should just fix the clients. In the long term, we should do it via bridges. Or we could just turn off the (IRC) suffix entirely on the bridge as the quickest fix.
This might be the best bet, in fact, given it doesn't matter that much whether the user is on IRC or not in practice on the Matrix side - and the userid tells you that if you /really/ care that much.
created: 2015-09-22 21:41:45.0
id: '12152'
issue: '11911'
type: comment
updateauthor: matthew
updated: 2015-09-22 21:41:45.0

22
static/jira/browse/BOTS-117 Normal file
View file

@ -0,0 +1,22 @@
---
summary: Moznet would like a suffix for Matrix users rather than an M-prefix - e.g -M
---
created: 2015-09-22 22:04:38.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11921'
key: BOTS-117
number: '117'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-09-24 10:50:51.0
status: '5'
type: '1'
updated: 2015-09-24 10:50:51.0
votes: '0'
watches: '1'
workflowId: '12024'
---
actions: null

32
static/jira/browse/BOTS-118 Normal file
View file

@ -0,0 +1,32 @@
---
summary: 'appservice-node: Shift url setting to method calls'
---
created: 2015-09-23 14:08:39.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
A number of people (myself included) tend to pass the wrong url to the constructor to AppServiceRegistration, we can clarify this by changing this to a no-arg constructor and explicitly exposing setAppServiceUrl and setHomeserverUrl which removes ambiguity
id: '11934'
key: BOTS-118
number: '118'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-09-24 11:17:15.0
status: '5'
type: '1'
updated: 2015-09-24 11:17:15.0
votes: '0'
watches: '2'
workflowId: '12037'
---
actions:
- author: kegan
body: 0.2.3
created: 2015-09-24 11:17:15.0
id: '12165'
issue: '11934'
type: comment
updateauthor: kegan
updated: 2015-09-24 11:17:15.0

40
static/jira/browse/BOTS-119 Normal file
View file

@ -0,0 +1,40 @@
---
summary: 'IRC AS: Do a looong exp backoff connecting to IRC servers'
---
created: 2015-09-24 09:57:29.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
It looks like the w3c IRC server went down at some point, but the bridge just tried for a couple of minutes then sulked and gave up trying to connect that user. Instead, we should continue trying exponentially into the days (and then give up) to help for cases like the server going down for some planned 24h maintenance
id: '11938'
key: BOTS-119
number: '119'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-11-16 16:48:18.0
status: '5'
type: '1'
updated: 2015-11-16 16:48:18.0
votes: '0'
watches: '2'
workflowId: '12041'
---
actions:
- author: neb
body: 'By @kegan:matrix.org: Rob Swain brings up a good point that a backoff in hours isn''t great since that means matrix users will be stuck waiting for the backoff before restoring the bridge, even if the IRC server is back up. Putting a cap in the tens of minutes probably won''t hurt anyone.'
created: 2015-09-24 10:17:37.0
id: '12164'
issue: '11938'
type: comment
updateauthor: neb
updated: 2015-09-24 10:17:37.0
- author: kegan
body: BOTS-135
created: 2015-11-16 16:48:18.0
id: '12366'
issue: '11938'
type: comment
updateauthor: kegan
updated: 2015-11-16 16:48:18.0

22
static/jira/browse/BOTS-12 Normal file
View file

@ -0,0 +1,22 @@
---
summary: IRC Bridge doesn't handle resends for unsent msgs
---
created: 2014-12-21 22:17:19.0
creator: matthew
description: ''
id: '10850'
key: BOTS-12
number: '12'
priority: '2'
project: '10101'
reporter: matthew
resolution: '1'
resolutiondate: 2015-07-31 11:56:46.0
status: '5'
type: '2'
updated: 2015-07-31 11:56:47.0
votes: '0'
watches: '1'
workflowId: '10950'
---
actions: null

43
static/jira/browse/BOTS-120 Normal file
View file

@ -0,0 +1,43 @@
---
summary: Nick templates don't get applied retrospectively
---
created: 2015-09-24 10:49:56.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
We currently store the nick used for an IRC client in prep for persisting their desired nick. This means that if you change the nick template in the config, it doesn't get applied to the IRC clients which were made before the change. We should do the trick we do for channels (from_config flag) to know if the nick was set by the user explicitly vs whatever the config says
id: '11939'
key: BOTS-120
number: '120'
priority: '2'
project: '10101'
reporter: neb
resolution: '2'
resolutiondate: 2016-06-02 10:23:10.0
status: '5'
type: '1'
updated: 2016-06-02 10:23:10.0
votes: '0'
watches: '3'
workflowId: '12042'
---
actions:
- author: illicitonion
body: |-
I'm not sure about this feature. I view the nick template as a "default if none is specified" rather than a "deterministic function to determine what your nick should always be in case you set it". As as user, I don't really want my nick changing underneath me.
I would rather provide a hook or something so that admins can rename individual accounts, and have people write a script to do this as a one-off if they really need, rather than change the default behaviour.
created: 2016-01-05 13:23:41.0
id: '12507'
issue: '11939'
type: comment
updateauthor: illicitonion
updated: 2016-01-05 13:23:41.0
- author: kegan
body: As discussed, this won't be done but will be possible via scripts.
created: 2016-06-02 10:23:10.0
id: '12951'
issue: '11939'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:23:10.0

20
static/jira/browse/BOTS-121 Normal file
View file

@ -0,0 +1,20 @@
---
summary: verto conferencing could generate custom push notifs to say when confs begin & end
---
created: 2015-09-28 22:11:51.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11961'
key: BOTS-121
number: '121'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2015-09-28 22:11:51.0
votes: '0'
watches: '1'
workflowId: '12064'
---
actions: null

32
static/jira/browse/BOTS-122 Normal file
View file

@ -0,0 +1,32 @@
---
summary: IRC AS needs a way to feed back to users if the connection bounces
---
created: 2015-10-01 01:54:57.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
1:31:20 AM Ryan Rix The IRC AS should notify users if the connection bounces, I keep having to re-nick myself but don't notice since I don't see those sorts of notices .
id: '11984'
key: BOTS-122
number: '122'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:57:05.0
status: '5'
type: '1'
updated: 2016-06-02 10:57:05.0
votes: '0'
watches: '2'
workflowId: '12087'
---
actions:
- author: kegan
body: Fixed on `develop`
created: 2016-06-02 10:57:05.0
id: '12974'
issue: '11984'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:57:05.0

20
static/jira/browse/BOTS-123 Normal file
View file

@ -0,0 +1,20 @@
---
summary: vertobridge conferencing fails badly on rooms with hidden history visibility
---
created: 2015-10-02 13:54:55.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11988'
key: BOTS-123
number: '123'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2015-10-02 13:54:55.0
votes: '0'
watches: '1'
workflowId: '12091'
---
actions: null

38
static/jira/browse/BOTS-124 Normal file
View file

@ -0,0 +1,38 @@
---
summary: 'IRC AS shouldn''t let you join rooms with aliases #network_foo:matrix.org which lack the 2nd hash'
---
created: 2015-10-05 15:15:04.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '11997'
key: BOTS-124
number: '124'
priority: '3'
project: '10101'
reporter: neb
resolution: '2'
resolutiondate: 2016-06-02 10:57:36.0
status: '5'
type: '1'
updated: 2016-06-02 10:58:00.0
votes: '0'
watches: '2'
workflowId: '12100'
---
actions:
- author: kegan
body: This is technically valid, as it represents a PM room.
created: 2016-06-02 10:57:36.0
id: '12975'
issue: '11997'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:57:36.0
- author: kegan
body: If it is UX we're worried about, we should be going towards irc:// rather than optimising for ease of typing the room aliases.
created: 2016-06-02 10:58:00.0
id: '12976'
issue: '11997'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:58:00.0

32
static/jira/browse/BOTS-125 Normal file
View file

@ -0,0 +1,32 @@
---
summary: Inviting an IRC AS virtual user into an existing Matrix room should work.
---
created: 2015-10-05 21:22:58.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
I've seen people do this several times and be disappointed that it doesn't spontaneously create a private IRC channel which mirrors the Matrix room in question
id: '12000'
key: BOTS-125
number: '125'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:24:04.0
status: '5'
type: '1'
updated: 2016-06-02 10:24:04.0
votes: '0'
watches: '2'
workflowId: '12103'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/44
created: 2016-06-02 10:24:01.0
id: '12952'
issue: '12000'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:24:01.0

22
static/jira/browse/BOTS-126 Normal file
View file

@ -0,0 +1,22 @@
---
summary: 'turn on irc->matrix join propagation for #ipfs'
---
created: 2015-10-17 13:48:39.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12027'
key: BOTS-126
number: '126'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2015-11-16 17:49:49.0
status: '5'
type: '1'
updated: 2015-11-16 17:49:49.0
votes: '0'
watches: '1'
workflowId: '12130'
---
actions: null

20
static/jira/browse/BOTS-127 Normal file
View file

@ -0,0 +1,20 @@
---
summary: nuke (IRC) suffixes from displaynames on irc bridge on moznet
---
created: 2015-10-21 18:30:34.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12035'
key: BOTS-127
number: '127'
priority: '2'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-26 09:48:43.0
votes: '0'
watches: '1'
workflowId: '12138'
---
actions: null

22
static/jira/browse/BOTS-128 Normal file
View file

@ -0,0 +1,22 @@
---
summary: conf user can get wedged in a room
---
created: 2015-10-26 09:47:52.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
A particular sequence of invites/candidates can result in the bridge thinking there is a user on the conf when really there isn't. Manifested as the voip user never leaving the group chat room. It looks like it wedged after receiving an m.call.invite, which was never passed on to FS. Need to check state machine edge cases.
id: '12041'
key: BOTS-128
number: '128'
priority: '2'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2015-10-26 09:47:52.0
votes: '0'
watches: '1'
workflowId: '12144'
---
actions: null

30
static/jira/browse/BOTS-129 Normal file
View file

@ -0,0 +1,30 @@
---
summary: If we're not syncing matrix->irc users, then irc->matrix bridge traffic is lost until someone speaks on the matrix side of the bridge
---
created: 2015-10-28 01:59:30.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12047'
key: BOTS-129
number: '129'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:59:06.0
status: '5'
type: '1'
updated: 2016-06-02 10:59:06.0
votes: '0'
watches: '2'
workflowId: '12150'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/59
created: 2016-06-02 10:59:06.0
id: '12977'
issue: '12047'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:59:06.0

30
static/jira/browse/BOTS-13 Normal file
View file

@ -0,0 +1,30 @@
---
summary: Support for mxc:// URLs in IRC when bridging images and other content.
---
created: 2014-12-24 17:19:44.0
creator: matthew
description: ''
id: '10868'
key: BOTS-13
number: '13'
priority: '2'
project: '10101'
reporter: matthew
resolution: '1'
resolutiondate: 2015-02-03 18:11:43.0
status: '5'
type: '2'
updated: 2015-02-03 18:11:44.0
votes: '0'
watches: '2'
workflowId: '10968'
---
actions:
- author: leonerd
body: This was solved a while ago
created: 2015-02-03 18:11:44.0
id: '11215'
issue: '10868'
type: comment
updateauthor: leonerd
updated: 2015-02-03 18:11:44.0

56
static/jira/browse/BOTS-130 Normal file
View file

@ -0,0 +1,56 @@
---
summary: 'IRC AS: Bad nick change confirmation messages'
---
created: 2015-10-28 16:25:49.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
<M-kegan> so the nick change request took about 50s
<M-kegan> which is Long
<M-kegan> in this time, a listener for nick changes is attached at the point where the NICK command is sent (there are no request/response pairings in IRC), and the nick change picked up was for someone else which that client instance is connected to
<M-kegan> the NICK change should've gone through though, so I'm surprised that your nick was still M-RyanRix
<M-kegan> I'm guessing what's happened here is that the NICK command was lost to the aether, which is why it took 50s (it won't resolve until it sees a NICK come back from the server)
id: '12050'
key: BOTS-130
number: '130'
priority: '2'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:25:24.0
status: '5'
type: '1'
updated: 2016-06-02 10:25:24.0
votes: '0'
watches: '2'
workflowId: '12153'
---
actions:
- author: kegan
body: |-
Relevant logs here:
{code}
2015-10-28 15:57:40 INFO:req [btvmw6amxv4s4] [M->I] @rrix:whatthefuck.computer wants to change their nick on irc.freenode.net to matrrix
2015-10-28 15:57:40 DEBUG:req [btvmw6amxv4s4] [M->I] Returning cached bridged client @rrix:whatthefuck.computer
[ At this point the NICK is sent (there is no more logging in the code) ]
2015-10-28 15:57:50 ERROR:req [btvmw6amxv4s4] [M->I] DELAYED - Taking too long. (>10000ms)
2015-10-28 15:58:31 INFO:req [btvmw6amxv4s4] [M->I] sendAction -> {"action":"notice","protocol":"matrix","body":"Nick changed from 'Lcawte|Away' to 'Lcawte'."}
2015-10-28 15:58:31 DEBUG:req [btvmw6amxv4s4] [M->I] SUCCESS - 51607 ms
{code}
It's worth noting that this connection was the main client claiming events for a lot of incoming messages, so the connection itself seemed fine.
created: 2015-10-28 16:36:22.0
id: '12277'
issue: '12050'
type: comment
updateauthor: kegan
updated: 2015-10-28 16:36:22.0
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/45
created: 2016-06-02 10:25:24.0
id: '12953'
issue: '12050'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:25:24.0

38
static/jira/browse/BOTS-131 Normal file
View file

@ -0,0 +1,38 @@
---
summary: The fact the AS is ratelimited by the HS makes IRC bridging to NickServ etc unusable
---
assignee: illicitonion
created: 2015-11-01 13:02:30.0
creator: matthew
description: |-
If I say 'help' to NickServ over an IRC bridge, the HS rate limiting makes the response totally unusable.
We should have a way to just turn off rate limiting for ASes, and rely on downstream HSes ratelimiting federation traffic (in future based on reputation). This is same semantics as an ircd not ratelimiting ircservices for the same reason.
id: '12060'
key: BOTS-131
number: '131'
priority: '1'
project: '10101'
reporter: matthew
status: '3'
type: '1'
updated: 2016-01-11 13:39:49.0
votes: '0'
watches: '2'
workflowId: '12163'
---
actions:
- author: erikj
body: |-
I'm slightly nervous that this'll trigger any federation ratelimiting that we have or will want to add. It would be unfortunate if a user on a random remote server could cause your server to be ratelimited by just PM'ing NickServ "help". I don't _think_ there are ratelimits that would be triggered by this behaviour, though.
Ideally, it would be nice if we could buffer the messages a bit, but that might adversely affect UX (as different messages no longer look like different messages).
To be honest, I don't know what the correct solution is here.
created: 2016-01-11 13:39:37.0
id: '12560'
issue: '12060'
type: comment
updateauthor: erikj
updated: 2016-01-11 13:39:49.0

31
static/jira/browse/BOTS-132 Normal file
View file

@ -0,0 +1,31 @@
---
summary: matrix-appservice-verto really needs to store the conference focus in room state somewhere to avoid splitbrains
---
created: 2015-11-02 23:47:42.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12073'
key: BOTS-132
number: '132'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-05 13:21:32.0
votes: '0'
watches: '2'
workflowId: '12176'
---
actions:
- author: illicitonion
body: |-
Right now the verto bridge is hard-coded that the user must be :matrix.org, and its name is deterministically generated from the room ID, which conveniently means that you can't invite multiple different verto users into a room to start multiple conferences in parallel.
We wish to remove the hard-coded username restrictions, which means we may end up in a situation where multiple conference users are present in one room. We should use a state event or something to choose which one the canonical one is.
created: 2016-01-05 13:21:32.0
id: '12506'
issue: '12073'
type: comment
updateauthor: illicitonion
updated: 2016-01-05 13:21:32.0

221
static/jira/browse/BOTS-133 Normal file
View file

@ -0,0 +1,221 @@
---
summary: A Matrix<->Gitter bridge
---
assignee: leonerd
created: 2015-11-05 17:31:10.0
creator: leonerd
description: |-
I would be eternally grateful if we had a Matrix<->Gitter solution. The current one that Freenode's #neovim uses directly between IRC and Gitter really annoys me (and several others). Their code lives at
https://github.com/finnp/gitter-irc-bot/blob/master/index.js
Fortunately, that's also in javascript, so I expect it ought to be easy enough for someone to take theabove and replace the IRC parts with Matrix AS library instead, and expand out from there.
id: '12087'
key: BOTS-133
number: '133'
priority: '3'
project: '10101'
reporter: leonerd
resolution: '1'
resolutiondate: 2016-05-04 18:18:15.0
status: '6'
type: '2'
updated: 2016-09-09 17:42:01.0
votes: '0'
watches: '1'
workflowId: '12190'
---
actions:
- author: leonerd
body: |-
Can someone (Likely Kegan?) give a 30-second reply on this? Ideally I'd love to see
* URLs of existing code examples of other bridges
* Information on how to run another one
There's more to creating a new bridge than simply writing some JS code. Even if we manage to have a piece of JS code that runs and does the right thing, where in practice does it run? I.e. all the operational-level questions.
created: 2015-12-06 21:50:51.0
id: '12429'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2015-12-06 21:50:51.0
- author: leonerd
body: |-
General "how to rnu a matrix.org AS" instructions now live at
https://etherpad.openmarket.com/MatrixDotOrgASDeployment
created: 2016-02-10 14:12:09.0
id: '12601'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-10 14:12:09.0
- author: leonerd
body: 'Step 1: created https://github.com/matrix-org/matrix-appservice-gitter'
created: 2016-02-10 14:12:30.0
id: '12602'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-10 14:12:30.0
- author: leonerd
body: 'Step 1a: actually wrote some code. It actually works; at least between (real) gitter and a temporary localhost synapse.'
created: 2016-02-10 19:43:28.0
id: '12604'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-10 19:43:28.0
- author: leonerd
body: |-
Steps 2 & 3 done.
{noformat}
gitteras@ldc-prd-matrix-003:~$
{noformat}
created: 2016-02-11 16:40:54.0
id: '12605'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-11 16:41:02.0
- author: leonerd
body: 'Step 4 done: picked 3511'
created: 2016-02-11 19:02:09.0
id: '12606'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-11 19:02:09.0
- author: leonerd
body: |-
Step 5 done:
{noformat}
gitteras@ldc-prd-matrix-003:~/matrix-appservice-gitter$ pwd
/home/gitteras/matrix-appservice-gitter
{noformat}
created: 2016-02-11 19:02:42.0
id: '12607'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-11 19:02:42.0
- author: leonerd
body: |-
Step 6 was done by the AS bridge library's {{-u -r}} options.
Step 8 is partly done; file committed into {{internal-config}} repo. Have not restarted synapse itself yet as that's a little disruptive to users, and it's not urgently needed yet. With that file in place, it'll be picked up next time the server gets restarted for some other reason, which is good enough. I'll continue the final steps sometime after that.
created: 2016-02-11 22:22:31.0
id: '12608'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-11 22:22:31.0
- author: leonerd
body: An initial attempt is now running, sufficient for me to 3-way bridge a test channel of mine.
created: 2016-02-16 18:06:17.0
id: '12613'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-16 18:06:17.0
- author: leonerd
body: |-
I now have a room bridged between Matrix and Gitter. The following steps were required to set that up:
* As a normal github user, create a new room on gitter.im attached to a github organisation.
* As that user on github, invite 'matrixbot' to join the organisation
* Log in to github as the matrixbot user and accept the invitation
* Add the 'matrixbot' user to the gitter.im room using the gitter UI
* Add the mapping of gitter room name to matrix room ID to {{internal-config}}'s {{gitter-config.yaml}} and restart the bridge AS
I expect there is some opportunity in here to streamline the process somewhat; at least in terms of having matrixbot itself perform the steps that required masquerading as it.
created: 2016-02-17 17:29:13.0
id: '12641'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-17 17:29:13.0
- author: leonerd
body: On further investigation, it seems that this can be reduced down if you create a new room on gitter that's not directly tied to a github organisation, because that gives you free ability to adjust the members of the room yourself. You can then invite matrixbot to that room, and once it's added to the config file it starts working. So that removes the tricky step of having to accept an organisation invite on github as the matrixbot user itself.
created: 2016-02-17 17:52:03.0
id: '12642'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-17 17:52:03.0
- author: leonerd
body: 'See also: this bug is mentioned by gitterHQ: https://github.com/gitterHQ/gitter/issues/1076'
created: 2016-02-18 18:26:57.0
id: '12643'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-02-18 18:26:57.0
- author: leonerd
body: |-
Now does some attempt at formatted messages.
Next things to consider:
* Setting avatar images on ghosted Matrix-side users
* Presence notifications
* Per-room optional topic sync
created: 2016-04-08 17:06:24.0
id: '12816'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-04-08 17:06:24.0
- author: leonerd
body: |-
Hm. Avatar setting is a little trickier than I thought - needs content upload to the homeserver's media repo because Vector will only display mxc:// URLs, not plain https ones.
Presence notification will require information out of gitter users - I'm asking gitterHQ about that now.
created: 2016-04-08 19:01:17.0
id: '12817'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-04-08 19:01:17.0
- author: leonerd
body: |-
Avatar copying is now done, give or take a bugfix needed to {{matrix-js-sdk}}
Presence (which Gitter calls "eyeballs") isn't quite supported by their official API, but the developers suggest to me:
{noformat}
@leonerd We have online presence eyeballs but that info is only accessible in halley/faye websockets api iirc
You use /v1/eyeballs but you need to pass a socketId
var realtimeClient = require('gitter-realtime-client');
var client = new realtimeClient.RealtimeClient({ token: GITTER_ACCESS_TOKEN });
// GET `/v1/eyeballs` with { socketId: client.getClientId() }
https://github.com/gitterHQ/realtime-client/blob/4eba1fc1e9ab920d2bf6e3c69c1f44923d4a9b2c/lib/realtime-client.js#L429
note, I am not sure if that code actually works but I think should get you pretty close
{noformat}
created: 2016-04-22 17:34:31.0
id: '12884'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-04-22 17:34:31.0
- author: leonerd
body: Presence is now done, via another little reacharound past the matrix-appservice-bridge code to get at the underlying js-sdk client object directly.
created: 2016-05-03 17:46:44.0
id: '12895'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-05-03 17:46:44.0
- author: leonerd
body: A basic attempt is now up and running. I'm tracking further small issues and bugs in github instead
created: 2016-05-04 18:18:15.0
id: '12896'
issue: '12087'
type: comment
updateauthor: leonerd
updated: 2016-05-04 18:18:15.0

22
static/jira/browse/BOTS-134 Normal file
View file

@ -0,0 +1,22 @@
---
summary: Relay errors if you try to PM a user who's gone offline
---
created: 2015-11-09 20:28:21.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12101'
key: BOTS-134
number: '134'
priority: '3'
project: '10101'
reporter: neb
resolution: '3'
resolutiondate: 2016-01-04 15:45:36.0
status: '5'
type: '1'
updated: 2016-01-04 15:45:36.0
votes: '0'
watches: '1'
workflowId: '12204'
---
actions: null

71
static/jira/browse/BOTS-135 Normal file
View file

@ -0,0 +1,71 @@
---
summary: 'IRC AS: Retry client connections forever'
---
created: 2015-11-10 09:34:01.0
creator: kegan
description: |-
When the bridge cannot communicate with the outside world, client connections should be retried ad infinitum. In the past this wasn't crucial since the {{MatrixBridge}} was the entity responsible for passing I->M traffic, but in a no-bot world, it is crucial that clients are reconnected at some point else they will lose I->M traffic.
Related logs:
{code}
2015-11-09 10:25:38 ERROR:client-connection Server: irc.freenode.net (M-RyanRix) Network Error: {
"msg": "Client-side ping timeout"
}
2015-11-09 10:26:18 ERROR:client-connection M-RyanRix@irc.freenode.net still not connected after 30000ms. Killing connection.
2015-11-09 10:26:50 ERROR:client-connection M-RyanRix@irc.freenode.net still not connected after 30000ms. Killing connection.
2015-11-09 10:27:25 ERROR:client-connection M-RyanRix@irc.freenode.net still not connected after 30000ms. Killing connection.
2015-11-09 10:27:25 ERROR:client-pool <ep6hb9fmh9cgo> Failed to reconnect M-Ryan Rix@irc.freenode.net
{code}
These also occurred afterwards which needs investigating:
{code}
2015-11-09 10:32:50 ERROR:client-connection Server: irc.freenode.net (M-RyanRix) Network Error: {
"code": "ENOTFOUND",
"errno": "ENOTFOUND",
"syscall": "getaddrinfo"
}
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:57 ERROR:client-connection M-RyanRix@irc.freenode.net RECV a notice event for a dead connection
2015-11-09 10:40:58 ERROR:client-connection M-RyanRix@irc.freenode.net: {"command":"ERROR","rawCommand":"ERROR","commandType":"normal","args":["Reconnecting too fast, throttled."]}
2015-11-09 10:41:41 ERROR:client-connection Server: irc.freenode.net (M-RyanRix) Network Error: {
"code": "ETIMEDOUT",
"errno": "ETIMEDOUT",
"syscall": "read"
}
2015-11-09 10:50:57 ERROR:client-connection Server: irc.freenode.net (M-RyanRix) Network Error: {
"msg": "Client-side ping timeout"
}
2015-11-09 10:50:57 ERROR:client-connection Server: irc.freenode.net (M-RyanRix) Network Error: {
"msg": "Client-side ping timeout"
}
{code}
A manual kick (by saying something on Matrix) was enough to kick this:
{code}
2015-11-09 22:50:50 INFO:irc-client <M-Ryan Rix@irc.freenode.net#c3b1iwkw0d4c4> (@rrix:whatthefuck.computer) Connecting to IRC server irc.freenode.net as M-RyanRix (user=rrixwhatth)
{code}
This ties back into reporting IRC connection state to Matrix users - BOTS-103
id: '12102'
key: BOTS-135
number: '135'
priority: '1'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2015-11-16 16:33:29.0
status: '5'
type: '1'
updated: 2015-11-16 16:33:29.0
votes: '0'
watches: '1'
workflowId: '12205'
---
actions: null

40
static/jira/browse/BOTS-136 Normal file
View file

@ -0,0 +1,40 @@
---
summary: 'IRC AS: IPv6 addresses need to be entered directly'
---
created: 2015-11-12 09:40:38.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
If you type a domain, it'll do the AAAA-lookup but then use v4, *obviously*. If it find a valid v6, it should really be using it. This is on Node v0.10.x
id: '12103'
key: BOTS-136
number: '136'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 11:00:49.0
status: '5'
type: '1'
updated: 2016-06-02 11:00:49.0
votes: '0'
watches: '3'
workflowId: '12206'
---
actions:
- author: illicitonion
body: Hopefully this magically gets fixed by updating node? Is there a trivial-ish way to test?
created: 2016-01-05 13:11:17.0
id: '12505'
issue: '12103'
type: comment
updateauthor: illicitonion
updated: 2016-01-05 13:11:17.0
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/60
created: 2016-06-02 11:00:49.0
id: '12978'
issue: '12103'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:00:49.0

24
static/jira/browse/BOTS-137 Normal file
View file

@ -0,0 +1,24 @@
---
summary: 'IRC AS: IPv6 support for outbound conns'
---
created: 2015-11-12 09:50:06.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
Each connected IRC client should be able to have a different v6 address. This needs the bridge to be able to bind to different source IPs f.e. client
id: '12104'
key: BOTS-137
number: '137'
priority: '3'
project: '10101'
reporter: neb
resolution: '3'
resolutiondate: 2016-01-04 17:22:43.0
status: '5'
type: '1'
updated: 2016-01-04 17:22:43.0
votes: '0'
watches: '1'
workflowId: '12207'
---
actions: null

32
static/jira/browse/BOTS-138 Normal file
View file

@ -0,0 +1,32 @@
---
summary: 'IRC AS: Broadcast matrix room'
---
created: 2015-11-16 17:16:07.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
It might be nice if IRC bridges could splat startup/stats/etc to a list of matrix rooms (e.g. #irc:matrix.org) which could then also provide poor Matrix users advance warning of any global connection woes
id: '12110'
key: BOTS-138
number: '138'
priority: '3'
project: '10101'
reporter: neb
resolution: '2'
resolutiondate: 2016-06-02 11:01:17.0
status: '5'
type: '1'
updated: 2016-06-02 11:01:17.0
votes: '0'
watches: '2'
workflowId: '12213'
---
actions:
- author: kegan
body: Punting for now.
created: 2016-06-02 11:01:17.0
id: '12979'
issue: '12110'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:01:17.0

25
static/jira/browse/BOTS-139 Normal file
View file

@ -0,0 +1,25 @@
---
summary: 'IRC AS: Prioritise ordering when connecting users on startup'
---
created: 2015-11-16 17:42:22.0
creator: kegan
description: |-
At least 1 client needs to be connected on a channel for it to be logged in Matrix. When we startup, clients are connected arbitrarily to the IRC network and channels. We should prioritise users who would bridge the most number of channels which are not currently being tracked.
This will reduce the impact of downtime when restarting the bridge.
id: '12111'
key: BOTS-139
number: '139'
priority: '2'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2015-11-26 10:15:23.0
status: '5'
type: '1'
updated: 2015-11-26 10:15:23.0
votes: '0'
watches: '1'
workflowId: '12214'
---
actions: null

28
static/jira/browse/BOTS-14 Normal file
View file

@ -0,0 +1,28 @@
---
summary: NEB should <br/> and not \n in HTML bodies
---
created: 2015-01-27 10:56:18.0
creator: kegan
description: ''
id: '10981'
key: BOTS-14
number: '14'
priority: '3'
project: '10101'
reporter: kegan
status: '1'
type: '1'
updated: 2015-01-27 10:59:50.0
votes: '0'
watches: '1'
workflowId: '11081'
---
actions:
- author: kegan
body: And should escape incoming webhook text before sending as HTML.
created: 2015-01-27 10:59:50.0
id: '11195'
issue: '10981'
type: comment
updateauthor: kegan
updated: 2015-01-27 10:59:50.0

25
static/jira/browse/BOTS-140 Normal file
View file

@ -0,0 +1,25 @@
---
summary: 'IRC AS: Handle more IRC errors rather than rage quitting'
---
created: 2015-11-18 14:37:14.0
creator: kegan
description: |-
If the bridge receives an IRC error code it doesn't recognise, it reconnects that client thinking that everything is ruined. It does this because we can't possibly handle every error code for each specific IRC server (some have the same err code to mean different things :( ). We should handle as many of the error codes as possible to avoid needlessly disconnecting and reconnecting people though.
In this case, Erik got reconnected because he set the topic in a channel he wasn't an op in (code {{482}}).
id: '12116'
key: BOTS-140
number: '140'
priority: '2'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-03-15 14:17:15.0
status: '5'
type: '1'
updated: 2016-03-15 14:17:15.0
votes: '0'
watches: '1'
workflowId: '12219'
---
actions: null

30
static/jira/browse/BOTS-141 Normal file
View file

@ -0,0 +1,30 @@
---
summary: Add PonyChat (irc.ponychat.net) as a bridged network
---
created: 2015-11-23 20:21:01.0
creator: xena
description: ''
id: '12134'
key: BOTS-141
number: '141'
priority: '3'
project: '10101'
reporter: xena
resolution: '2'
resolutiondate: 2015-12-05 02:06:12.0
status: '5'
type: '3'
updated: 2015-12-05 02:06:12.0
votes: '0'
watches: '1'
workflowId: '12237'
---
actions:
- author: xena
body: This may be irellevant. I have been working on a more tightly integrated setup.
created: 2015-12-02 17:28:41.0
id: '12414'
issue: '12134'
type: comment
updateauthor: xena
updated: 2015-12-02 17:28:41.0

146
static/jira/browse/BOTS-142 Normal file
View file

@ -0,0 +1,146 @@
---
summary: 'IRC AS: Duplicate messages matrix-side'
---
created: 2015-11-25 10:04:13.0
creator: kegan
description: |-
24 Nov 23:38
IRC Side:
{code}
23:38 * M-intelfx (intelfxint@gateway/shell/matrix.org/x-ywtwwlgnaeegvvln) has joined #matrix
23:38 <M-intelfx> The beta Vector client is very nice, btw.
23:40 <M-intelfx> Huh? Why am I duplicated by the IRC bridge? :)
23:57 * 20WACI3YG (intelfxmat@gateway/shell/matrix.org/x-qiadbxfsrtnuguyz) has joined #matrix
23:57 <20WACI3YG> Let's try this way.
{code}
Matrix side:
{code}
Ivan Shapovalov (@intelfx:intelfx.name): The beta Vector client is very nice, btw.
M-intelfx (IRC) joined the room.
M-intelfx (IRC): The beta Vector client is very nice, btw.
Ivan Shapovalov (@intelfx:intelfx.name): Huh? Why am I duplicated by the IRC bridge? :)
M-intelfx (IRC): Huh? Why am I duplicated by the IRC bridge? :)
intelfx (@intelfx:matrix.org): Let's try this way.
{code}
Logs:
{code}
2015-11-24 23:38:45 INFO:req [bbyxjzv0l3www] [M->I] m.room.message usr=@intelfx:intelfx.name rm=!cURbafjkfsMDVwdRDQ:matrix.org
2015-11-24 23:38:45 INFO:req [bbyxjzv0l3www] [M->I] Relaying message in #matrix on irc.freenode.net
2015-11-24 23:38:45 DEBUG:req [bbyxjzv0l3www] [M->I] Returning cached bridged client @intelfx:intelfx.name
2015-11-24 23:38:45 INFO:req [bbyxjzv0l3www] [M->I] Sending msg in #matrix as M-intelfx
2015-11-24 23:38:45 DEBUG:irc-client <M-intelfx@irc.freenode.net#a0j947z7d5sgk> (@intelfx:intelfx.name) Joining channel #matrix
2015-11-24 23:38:45 DEBUG:irc-client <M-intelfx@irc.freenode.net#a0j947z7d5sgk> (@intelfx:intelfx.name) Joined channel #matrix
2015-11-24 23:38:45 DEBUG:req [bbyxjzv0l3www] [M->I] SUCCESS - 391 ms
2015-11-24 23:38:47 INFO:req [jfxlq7c2ll440] [I->M] onMessage: irc.freenode.net from=M-intelfx (null@irc.freenode.net) to=#matrix
2015-11-24 23:38:47 DEBUG:matrix-js-sdk POST http://matrix.org/_matrix/client/v2_alpha/register (AS) Body: {"auth":{},"username":"freenode_M-intelfx"}
2015-11-24 23:38:50 INFO:req [jfxlq7c2ll440] [I->M] Mapped to {"isVirtual":true,"protocol":"matrix","userId":"@freenode_M-intelfx:matrix.org","displayName":"M-intelfx (IRC)"}
2015-11-24 23:38:52 DEBUG:req [jfxlq7c2ll440] [I->M] SUCCESS - 5651 ms
{code}
It should've picked up the I->M side was a virtual user, but it failed to. It thought it was using a cached client so the interesting bit is what is the state of that connection. The connection looked to be alive (receiving pings, though annoyingly we don't log the connection instance ID in this). The timings of the pings and the origin server is illuminating though:
{code}
2015-11-24 23:31:48 DEBUG:client-connection Received ping from cameron.freenode.net directed at M-intelfx
[24s]
2015-11-24 23:32:12 DEBUG:client-connection Received ping from asimov.freenode.net directed at M-intelfx
[1m 46s]
2015-11-24 23:33:58 DEBUG:client-connection Received ping from cameron.freenode.net directed at M-intelfx
[29s]
2015-11-24 23:34:27 DEBUG:client-connection Received ping from asimov.freenode.net directed at M-intelfx
[1m 41s]
2015-11-24 23:36:08 DEBUG:client-connection Received ping from cameron.freenode.net directed at M-intelfx
[34s]
2015-11-24 23:36:42 DEBUG:client-connection Received ping from asimov.freenode.net directed at M-intelfx
[1m 36s]
2015-11-24 23:38:18 DEBUG:client-connection Received ping from cameron.freenode.net directed at M-intelfx
{code}
You can clearly see pings from 2 servers, indicating 2 connection instances for this nick. Grepping further afield, it looks like:
{code}
2015-11-16 17:27:54 INFO:irc-client <M-intelfx@irc.freenode.net#a0j947z7d5sgk> (@intelfx:intelfx.name) Connecting to IRC server irc.freenode.net as M-intelfx (user=intelfxint)
2015-11-16 17:27:56 DEBUG:irc-client <M-intelfx@irc.freenode.net#a0j947z7d5sgk> (@intelfx:intelfx.name) connected!
2015-11-21 17:27:56 INFO:irc-client <M-intelfx@irc.freenode.net#a0j947z7d5sgk> (@intelfx:intelfx.name) Idle timeout has expired
2015-11-21 17:27:56 INFO:irc-client <M-intelfx@irc.freenode.net#a0j947z7d5sgk> (@intelfx:intelfx.name) Not disconnecting because irc.freenode.net is mirroring matrix membership lists
{code}
His matrix.org user:
{code}
2015-11-16 17:28:39 INFO:irc-client <M-intelfx@irc.freenode.net#bion5hs2eo848> (@intelfx:matrix.org) Connecting to IRC server irc.freenode.net as M-intelfx (user=intelfxmat)
2015-11-16 17:28:41 DEBUG:client-pool Connected with nick 'M-intelfx1' instead of desired nick 'M-intelfx'
2015-11-22 03:43:38 ERROR:client-connection M-intelfx@irc.freenode.net: {"command":"ERROR","rawCommand":"ERROR","commandType":"normal","args":["Closing Link: gateway/shell/matrix.org/x-ufiwesbeopqhxsaf (Ping timeout: 244 seconds)"]}
2015-11-22 03:43:38 INFO:client-connection disconnect()ing M-intelfx@irc.freenode.net - raw_error
2015-11-22 03:43:38 DEBUG:client-pool onClientDisconnected: <bion5hs2eo848> Reconnecting M-intelfx1@irc.freenode.net in 10000ms
2015-11-22 03:43:48 INFO:irc-client <M-intelfx@irc.freenode.net#kakx3kvehj44c> (@intelfx:matrix.org) Connecting to IRC server irc.freenode.net as M-intelfx (user=intelfxmat)
2015-11-22 03:45:46 ERROR:client-connection M-intelfx@irc.freenode.net still not connected after 30000ms. Killing connection.
2015-11-22 03:45:46 INFO:client-connection disconnect()ing M-intelfx@irc.freenode.net - timeout
2015-11-22 03:46:24 DEBUG:irc-client <M-intelfx@irc.freenode.net#kakx3kvehj44c> (@intelfx:matrix.org) connected!
2015-11-22 03:46:24 DEBUG:irc-client <M-intelfx@irc.freenode.net#kakx3kvehj44c> (@intelfx:matrix.org) _keepAlive; Restarting 432000s idle timeout
2015-11-22 03:46:24 INFO:client-pool <kakx3kvehj44c> Reconnected M-intelfx@irc.freenode.net
2015-11-22 03:55:27 INFO:irc-client <M-intelfx@irc.freenode.net#kakx3kvehj44c> (@intelfx:matrix.org) NICK: Nick changed from 'M-intelfx' to '20WACI3YG'.
{code}
So this actually looks like it is *not* a connection problem, but a logic error in the bridge which is fetching the wrong (matrix.org) connection when it really meant to fetch the intelfx.name connection.
This is plausible since we still wrongly key off the "desired nick" for much internal state, which is *usually* okay but in this case is not. This never clashes with {{!nick}} commands because that is the "actual nick" rather than the "desired" one. We should instead be keying off the ident username which we can guarantee has a 1:1 mapping between user_id and client connection.
id: '12135'
key: BOTS-142
number: '142'
priority: '2'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-06-02 10:12:34.0
status: '5'
type: '1'
updated: 2016-06-02 10:12:34.0
votes: '0'
watches: '1'
workflowId: '12238'
---
actions:
- author: kegan
body: |-
So this is a story about how you should *never trust your IRC server*. But first, some architecture:
- The bridge maintains a map of nick -> IRC Client connection. This nick is initially set to the "desired" nick which is used before we've connected to the IRC server and is clobbered when we actually know what nick we got. This is kept in sync when {{NICK}} changes come down, so is constantly changing so we know who our clients are.
- In the nominal case, this works well. The IRC server forbids clashes so we don't run the risk of clobbering our nicks, right? But then, _a wild netsplit appears!_.
- At 3:43 am on 22 Nov a netsplit occurred. One of these users got disconnected and tried to reconnect. It did eventually, but it _got assigned to an existing nick_ since there was an ongoing netsplit. This clobbered the client connection in the map.
- This was resolved at 3:55am but the damage was already done. The server assigned the now clashing nick to an arbitrary value {{20WACI3YG}}. The netsplit clobbered the existing connection instance. This meant when the bridge tried to look up existing clients with the incoming nick which was clobbered it didn't find anything, and so treated it as a genuine IRC message, resulting in the dupe.
created: 2015-11-25 17:45:11.0
id: '12381'
issue: '12135'
type: comment
updateauthor: kegan
updated: 2015-11-25 17:45:11.0
- author: kegan
body: As for fixes, we can store this as a map of Nick -> [Client] which would prevent us clobbering the client instance. Lookups on a nick would nominally return the right thing still. Nick changes would be *hilarious* to handle correctly because we don't know *which client* the {{NICK}} change event refers to. Yay.
created: 2015-11-25 17:47:26.0
id: '12382'
issue: '12135'
type: comment
updateauthor: kegan
updated: 2015-11-25 17:47:26.0
- author: kegan
body: This can be somewhat fixed by broadcasting the IRC client with the {{nick-change}} event such that you know which client instance's nick was changed.
created: 2015-11-25 17:58:34.0
id: '12383'
issue: '12135'
type: comment
updateauthor: kegan
updated: 2015-11-25 17:58:34.0
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/27
created: 2016-06-02 10:12:34.0
id: '12943'
issue: '12135'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:12:34.0

54
static/jira/browse/BOTS-143 Normal file
View file

@ -0,0 +1,54 @@
---
summary: IRC bridge should not try to relay HTML for Matrix->IRC, other than possibly bold, and use the plain text instead
---
created: 2015-11-29 15:25:50.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12150'
key: BOTS-143
number: '143'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 11:02:16.0
status: '5'
type: '1'
updated: 2016-06-02 11:02:16.0
votes: '0'
watches: '3'
workflowId: '12253'
---
actions:
- author: kegan
body: Err why? This will ruin a lot of github spam. I thought the whole point was to bridge as accurately as possible.
created: 2015-11-30 08:39:34.0
id: '12386'
issue: '12150'
type: comment
updateauthor: kegan
updated: 2015-11-30 08:39:34.0
- author: matthew
body: the problem that people were complaining about is that they write some markdown to render some sexy HTML, and expect to see the markdown on IRC rather than a bastardised version of the HTML. I.e. `*foo*` should be rendered with the asterisks on IRC, rather than rendered to italics which are then dropped.
created: 2015-12-01 23:33:36.0
id: '12411'
issue: '12150'
type: comment
updateauthor: matthew
updated: 2015-12-01 23:33:36.0
- author: neb
body: 'By @kegan:matrix.org: We do not know that the message body is actually Markdown. It cannot be changed without also screwing over Github/Jenkins NEB messages. If we implemented the matrix-doc rich text PR then we could do this.'
created: 2015-12-02 07:21:15.0
id: '12412'
issue: '12150'
type: comment
updateauthor: neb
updated: 2015-12-02 07:21:15.0
- author: kegan
body: The underlying problem here was that the bridge wasn't doing all the conversions correctly, resulting in things being missed/subtlety being dropped. This is now fixed (if there are tags that are unhandled, the bridge sends the fallback body instead).
created: 2016-06-02 11:02:16.0
id: '12980'
issue: '12150'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:02:16.0

165
static/jira/browse/BOTS-144 Normal file
View file

File diff suppressed because one or more lines are too long

52
static/jira/browse/BOTS-145 Normal file
View file

@ -0,0 +1,52 @@
---
summary: Cannot create bridged IRC channel for a foreign homeserver
---
created: 2015-12-02 17:33:23.0
creator: xena
description: |-
I have a homeserver named yochat.biz, I wanted to have it be able to bridge #ponydevs on PonyChat with #ponydevs:matrix.org. Adding the bridge settings for the long ID for yochat.biz -> matrix.org did not work at all.
What is the process for having a foreign homeserver act as an IRC bridge for a local channel?
id: '12169'
key: BOTS-145
number: '145'
priority: '3'
project: '10101'
reporter: xena
resolution: '4'
resolutiondate: 2016-06-22 15:30:55.0
status: '5'
type: '1'
updated: 2016-06-22 15:30:55.0
votes: '0'
watches: '3'
workflowId: '12272'
---
actions:
- author: matthew
body: |-
Bridging based on room id like this should work; there are no such things as "local" channels as the rooms are equal over all servers. The only time this fails would be if you were bridging the room based on its alias, but you're not. And even if you were, you could get around it by creating a #ponydevs:yochat.biz that points to the right room id.
Does the bridge work otherwise?
created: 2015-12-10 01:27:05.0
id: '12454'
issue: '12169'
type: comment
updateauthor: matthew
updated: 2015-12-10 01:27:05.0
- author: kegan
body: Need more information on the setup here, as I'm not sure what is being done.
created: 2016-06-02 11:07:32.0
id: '12984'
issue: '12169'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:07:32.0
- author: kegan
body: Spoken to Xena about it, and this is no longer an issue.
created: 2016-06-22 15:30:55.0
id: '13014'
issue: '12169'
type: comment
updateauthor: kegan
updated: 2016-06-22 15:30:55.0

21
static/jira/browse/BOTS-146 Normal file
View file

@ -0,0 +1,21 @@
---
summary: Need to unbodge the group functionality from the SMS AS
---
assignee: dbkr
created: 2015-12-02 23:33:24.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12172'
key: BOTS-146
number: '146'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-04 15:49:37.0
votes: '0'
watches: '1'
workflowId: '12275'
---
actions: null

55
static/jira/browse/BOTS-147 Normal file
View file

@ -0,0 +1,55 @@
---
summary: 'IRC AS: Fatal exception (network)'
---
created: 2015-12-15 09:21:01.0
creator: kegan
description: |-
Bridge restarted with:
{code}
2015-12-15 07:50:39 ERROR:matrix-js-sdk GET http://matrix.org/_matrix/client/api/v1/initialSync (AS) HTTP null Error: {"code":"ECONNRESET"}
2015-12-15 07:50:39 ERROR:main FATAL EXCEPTION
2015-12-15 07:50:39 ERROR:main Error: socket hang up
at createHangUpError (http.js:1472:15)
at Socket.socketOnEnd [as onend] (http.js:1568:23)
at Socket.g (events.js:180:16)
at Socket.EventEmitter.emit (events.js:117:20)
at _stream_readable.js:920:16
at process._tickCallback (node.js:415:13)
2015-12-15 07:50:39 ERROR:main Terminating (exitcode=1)
{code}
Other failures in the logs:
{code}
2015-12-13 06:46:32 ERROR:main FATAL EXCEPTION
2015-12-13 06:46:32 ERROR:main Error: read ECONNRESET
at errnoException (net.js:901:11)
at TCP.onread (net.js:556:19)
2015-12-13 06:46:32 ERROR:main Terminating (exitcode=1)
{code}
{code}
2015-11-28 05:56:49 ERROR:main FATAL EXCEPTION
2015-11-28 05:56:49 ERROR:main Error: read ECONNRESET
at errnoException (net.js:901:11)
at TCP.onread (net.js:556:19)
2015-11-28 05:56:49 ERROR:main Terminating (exitcode=1)
{code}
Why the hell is the HTTP/network library throwing uncaught Errors? They should all be rejecting promises. The stack doesn't look like it is touching the bridge code...
id: '12210'
key: BOTS-147
number: '147'
priority: '1'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-06-02 10:07:30.0
status: '5'
type: '1'
updated: 2016-06-02 10:07:30.0
votes: '0'
watches: '1'
workflowId: '12313'
---
actions: null

32
static/jira/browse/BOTS-148 Normal file
View file

@ -0,0 +1,32 @@
---
summary: Scrollback from remote newly-joined IRC bridge rooms produces blank events
---
created: 2015-12-27 01:14:46.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
See convo around $145117852980PFsAj:terracrypt.net on Matrix HQ
id: '12251'
key: BOTS-148
number: '148'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 11:32:43.0
status: '5'
type: '1'
updated: 2016-06-02 11:32:43.0
votes: '0'
watches: '2'
workflowId: '12354'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/66
created: 2016-06-02 11:32:43.0
id: '12988'
issue: '12251'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:32:43.0

24
static/jira/browse/BOTS-149 Normal file
View file

@ -0,0 +1,24 @@
---
summary: If you start two PMs with an IRC user one of them silently fails
---
created: 2015-12-31 18:19:49.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
I accidentally started two PMs by double-clicking on iOS. The first one was silently blackholed. The second worked.
id: '12259'
key: BOTS-149
number: '149'
priority: '3'
project: '10101'
reporter: neb
resolution: '3'
resolutiondate: 2016-01-04 15:53:48.0
status: '5'
type: '1'
updated: 2016-01-04 15:53:48.0
votes: '0'
watches: '1'
workflowId: '12362'
---
actions: null

31
static/jira/browse/BOTS-15 Normal file
View file

@ -0,0 +1,31 @@
---
summary: NEB should announce comments on line numbers on PRs
---
assignee: illicitonion
created: 2015-02-06 09:40:09.0
creator: kegan
description: ''
id: '11006'
key: BOTS-15
number: '15'
priority: '2'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2015-09-11 15:01:31.0
status: '6'
type: '1'
updated: 2015-09-11 15:01:31.0
votes: '0'
watches: '2'
workflowId: '11106'
---
actions:
- author: illicitonion
body: https://github.com/Kegsay/Matrix-NEB/pull/8
created: 2015-09-11 14:13:10.0
id: '12128'
issue: '11006'
type: comment
updateauthor: illicitonion
updated: 2015-09-11 14:13:10.0

32
static/jira/browse/BOTS-150 Normal file
View file

@ -0,0 +1,32 @@
---
summary: Multiple PMs may result in lost messages
---
created: 2016-01-10 19:17:14.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
<Charlie> ah, I did it again. the matrix user left the IRC PM room, the IRC user sent another message, and the matrix user never sees it and doesn't get any indication that the room might have more content. no second invitation. the IRC bridge seems unaware of the matrix user having left the room
id: '12287'
key: BOTS-150
number: '150'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:38:30.0
status: '5'
type: '1'
updated: 2016-06-02 10:38:30.0
votes: '0'
watches: '2'
workflowId: '12392'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/41
created: 2016-06-02 10:38:30.0
id: '12960'
issue: '12287'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:38:30.0

22
static/jira/browse/BOTS-151 Normal file
View file

@ -0,0 +1,22 @@
---
summary: IRC bridge needs an if (chans == 0) then disconnect() check
---
created: 2016-01-14 16:38:34.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12302'
key: BOTS-151
number: '151'
priority: '3'
project: '10101'
reporter: neb
resolution: '3'
resolutiondate: 2016-01-14 17:59:53.0
status: '5'
type: '1'
updated: 2016-01-14 17:59:53.0
votes: '0'
watches: '1'
workflowId: '12407'
---
actions: null

30
static/jira/browse/BOTS-152 Normal file
View file

@ -0,0 +1,30 @@
---
summary: IRC->Matrix PMs are ignored unless the IRC nick being PMed has precisely the right case
---
created: 2016-01-15 10:29:23.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12306'
key: BOTS-152
number: '152'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 11:04:07.0
status: '5'
type: '1'
updated: 2016-06-02 11:04:07.0
votes: '0'
watches: '2'
workflowId: '12411'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/61
created: 2016-06-02 11:04:07.0
id: '12981'
issue: '12306'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:04:07.0

20
static/jira/browse/BOTS-153 Normal file
View file

@ -0,0 +1,20 @@
---
summary: Jon gets 'An unknown error has occurred. Please try again.' from PayPal when trying to activate the OM SMS gateway
---
created: 2016-01-15 18:24:53.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12308'
key: BOTS-153
number: '153'
priority: '1'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-15 18:24:53.0
votes: '0'
watches: '1'
workflowId: '12413'
---
actions: null

29
static/jira/browse/BOTS-154 Normal file
View file

@ -0,0 +1,29 @@
---
summary: Synapse on startup can fail to send pending transactions to ASes
---
created: 2016-01-20 10:44:43.0
creator: kegan
description: |-
_Filing this as a BOTS issue rather than SYN to keep all AS/bridge related "stuff" together_
Context:
The IRC bridge relayed a matrix message that was 3 days old.
Details:
The message was sent as the server was shot in the head. The entry was added to the db as something that should be sent. Then it restarted. On startup, the recoverer checks for all "down" (prev connection failures) ASes and then tries to retry to those ASes. But in this case, the freenode bridge never had any connectivity problems so it wasn't ever marked as down (but it still had pending items to send). As a result, the message was never sent to the AS until there was a connection failure, which happened 3 days later.
This should be a pretty simple fix to check for pending transactions on startup as opposed to down status, since that's what really counts.
id: '12321'
key: BOTS-154
number: '154'
priority: '2'
project: '10101'
reporter: kegan
status: '1'
type: '1'
updated: 2016-01-20 10:44:43.0
votes: '0'
watches: '1'
workflowId: '12426'
---
actions: null

82
static/jira/browse/BOTS-155 Normal file
View file

@ -0,0 +1,82 @@
---
summary: IRC AS can fall silent yet still ack messages
---
created: 2016-01-20 11:38:35.0
creator: kegan
description: |-
I was looking into why the following message was not relayed from Matrix to IRC (#matrix FN):
{code}
{
"origin_server_ts": 1453246685337, // Tue 2016-01-19 23:38:05 GMT
"sender": "@LeoNerd:matrix.org",
"event_id": "$145324668519864fwpTO:matrix.org",
"age": 36640140,
"unsigned": {
"age": 36640140
},
"content": {
"body": "Are we still on?",
"msgtype": "m.text"
},
"room_id": "!cURbafjkfsMDVwdRDQ:matrix.org",
"user_id": "@LeoNerd:matrix.org",
"type": "m.room.message"
}
{code}
I do not know which txn ID this event was bundled into. What I do know is that the IRC AS was 200 OKing /transactions/\{txnId\} requests, but they were taking a while around this time. Some timings:
{code}
23:37:48 - txn 9556413
23:37:52 - OK (4s)
23:38:00 - txn 9556414
23:38:09 - OK (9s)
23:38:09 - txn 9556415
23:38:19 - OK (10s)
23:38:19 - txn 9556416
23:38:23 - OK (4s)
{code}
Grepping the IRC AS logs showed nothing for these transactions. It turns out there are no logs at all from 2016-01-19 21:01:04 until it was restarted at 2016-01-20 00:36:24.
Several issues here:
- Why no logs?
- Why no bridging (Synapse seems to think it got to the AS, but without logs we don't know why it failed to bridge)
- Why so long? These requests should be responding much quicker than in the seconds.
There's also the following (this happened to a bunch of messages):
{code}
2016-01-19 20:55:46 INFO:req [7h92q3cw42gwc] [I->M] onMessage: irc.freenode.net from=zapotah (null@irc.freenode.net) to=##networking
2016-01-19 20:55:59 ERROR:req [7h92q3cw42gwc] [I->M] DELAYED - Taking too long. (>10000ms)
2016-01-19 21:01:01 ERROR:req [7h92q3cw42gwc] [I->M] DEAD - Removing request (>310000ms)
{code}
No other logs for that request ID, but other messages were still flowing, so possible edge case code path?
Prometheus logs around this time show Something Bad happening around 20:20. The success rate of messages drops significantly (the freenode bridge crying for help) and the delay/fail rate increases (from delayed/dead messages). This persists until the bridge restarts. Logs around this time shows it all starts to kick off at 2016-01-19 20:22:39. There's nothing obvious in the logs that indicates that anything is catastrophically wrong.
I speculate that something (perhaps the DB?) failed abruptly which then caused all of this. I think this because the AS was still 200 OKing transactions (this never hits the DB, it just emits the event then sends the OK) and there's no logging at all beyond the initial event emission (and then timeouts for delay/dead). This would make sense if the DB fell over because the first thing {{onMessage}} does is hit the DB for the list of mapped rooms {{getIrcChannelsForRoomId}}
id: '12323'
key: BOTS-155
number: '155'
priority: '1'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-06-02 10:02:39.0
status: '6'
type: '1'
updated: 2016-06-02 10:02:39.0
votes: '0'
watches: '1'
workflowId: '12428'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/36
created: 2016-06-02 10:02:39.0
id: '12938'
issue: '12323'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:02:39.0

22
static/jira/browse/BOTS-156 Normal file
View file

@ -0,0 +1,22 @@
---
summary: NEB's github plugin should mangle @mentions to avoid pissing off random GH users
---
created: 2016-01-21 00:03:14.0
creator: neb
description: |-
Submitted by @irc_Arathorn:openmarket.com
I suggest we insert a zero-width space U+200B between the @ and the mention to avoid accidentally pinging Mr Mention :/
id: '12328'
key: BOTS-156
number: '156'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-01-21 00:03:14.0
votes: '0'
watches: '1'
workflowId: '12433'
---
actions: null

30
static/jira/browse/BOTS-157 Normal file
View file

@ -0,0 +1,30 @@
---
summary: OtherSqueaky's inverted colour scheme doesn't map to Matrix
---
created: 2016-01-22 18:49:06.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12343'
key: BOTS-157
number: '157'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 11:05:01.0
status: '5'
type: '1'
updated: 2016-06-02 11:05:01.0
votes: '0'
watches: '2'
workflowId: '12448'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/62
created: 2016-06-02 11:05:01.0
id: '12982'
issue: '12343'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:05:01.0

32
static/jira/browse/BOTS-158 Normal file
View file

@ -0,0 +1,32 @@
---
summary: IRC virtual users are shown as a weird mix of @freenode_foo:matrix.org user IDs and displaynames
---
created: 2016-01-23 01:09:28.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
See #matrix:matrix.org/$145351116337607hGbfy:matrix.org for more details
id: '12346'
key: BOTS-158
number: '158'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 11:06:44.0
status: '5'
type: '1'
updated: 2016-06-02 11:06:44.0
votes: '0'
watches: '2'
workflowId: '12451'
---
actions:
- author: kegan
body: This is now fixed (ran the one-time script to fixup all `@freenode_` display names).
created: 2016-06-02 11:06:44.0
id: '12983'
issue: '12346'
type: comment
updateauthor: kegan
updated: 2016-06-02 11:06:44.0

43
static/jira/browse/BOTS-159 Normal file
View file

@ -0,0 +1,43 @@
---
summary: 'IRC AS: Guest users don''t work'
---
created: 2016-01-25 18:05:47.0
creator: kegan
description: |-
See https://github.com/matrix-org/matrix-appservice-irc/issues/12
{code}
2016-01-17 03:17:10 ERROR:client-connection XS--qKKCJKOmKjcpcjvHdO@scootaloo.ponychat.net: {"command":"ERROR","rawCommand":"ERROR","commandType":"normal","args":["Closing Link: ns501493.ip-142-4-215.net (Invalid username [-qkkcjkomk])"]}
{code}
id: '12349'
key: BOTS-159
number: '159'
priority: '1'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-06-02 10:06:02.0
status: '5'
type: '1'
updated: 2016-06-02 10:06:02.0
votes: '0'
watches: '1'
workflowId: '12454'
---
actions:
- author: kegan
body: They do now, because we use numeric IDs. Underlying bug needs to be fixed still.
created: 2016-03-04 17:35:14.0
id: '12749'
issue: '12349'
type: comment
updateauthor: kegan
updated: 2016-03-04 17:35:14.0
- author: kegan
body: See GH issue.
created: 2016-06-02 10:06:02.0
id: '12940'
issue: '12349'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:06:02.0

49
static/jira/browse/BOTS-160 Normal file
View file

@ -0,0 +1,49 @@
---
summary: 'IRC AS: Tight-looping on netsplits'
---
created: 2016-02-01 10:13:34.0
creator: kegan
description: |-
The IRC bridge wedged yesterday afternoon. The logs were unhelpful:
{code}
[...] Lots more QUITs
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
2016-01-31 12:25:04 DEBUG:irc-client-events M-liberdiko1 is claiming a hash for cmd QUIT
[ Matthew restarts bridge ]
2016-01-31 14:25:19 INFO:stats statsd endpoint: {"hostname":"127.0.0.1","port":9878,"jobName":"freenode"} (name: freenode)
2016-01-31 14:25:19 INFO:irc-ident Configuring ident server => {"enabled":true,"port":1113}
{code}
No logs for 2 hours! Looking at other monitoring on this box indicates that CPU usage was taking up a whole core aka it was tight looping for 2 hours. Looking at freenode when this happened and there was a *massive* netsplit which I suspect triggered this behaviour.
Without logs this will be an interesting investigation (though the lack of logs is also incredibly informative as it hints at where in the stack the tight loop may be)
id: '12357'
key: BOTS-160
number: '160'
priority: '1'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-06-02 10:02:46.0
status: '6'
type: '1'
updated: 2016-06-02 10:02:46.0
votes: '0'
watches: '1'
workflowId: '12462'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/36
created: 2016-06-02 10:02:46.0
id: '12939'
issue: '12357'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:02:46.0

30
static/jira/browse/BOTS-161 Normal file
View file

@ -0,0 +1,30 @@
---
summary: Guest access and IRC plays badly as idents can't start with a -
---
created: 2016-02-01 19:20:25.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12359'
key: BOTS-161
number: '161'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:40:30.0
status: '5'
type: '1'
updated: 2016-06-02 10:40:30.0
votes: '0'
watches: '2'
workflowId: '12464'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/12
created: 2016-06-02 10:40:30.0
id: '12961'
issue: '12359'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:40:30.0

38
static/jira/browse/BOTS-162 Normal file
View file

@ -0,0 +1,38 @@
---
summary: Bridge disconnects and incorrectly starts up when synapse restarts
---
created: 2016-02-11 18:40:25.0
creator: erikj
description: ''
id: '12388'
key: BOTS-162
number: '162'
priority: '1'
project: '10101'
reporter: erikj
resolution: '1'
resolutiondate: 2016-06-02 10:00:36.0
status: '6'
type: '1'
updated: 2016-06-02 10:00:36.0
votes: '0'
watches: '3'
workflowId: '12493'
---
actions:
- author: matthew
body: In the ircas logs lots of node exiting with error 1 :/
created: 2016-02-11 22:53:14.0
id: '12609'
issue: '12388'
type: comment
updateauthor: matthew
updated: 2016-02-11 22:53:14.0
- author: kegan
body: Sounds like this was caused by BOTS-170
created: 2016-03-04 17:34:22.0
id: '12748'
issue: '12388'
type: comment
updateauthor: kegan
updated: 2016-03-04 17:34:22.0

22
static/jira/browse/BOTS-163 Normal file
View file

@ -0,0 +1,22 @@
---
summary: NEB setup should be a bit easier
---
created: 2016-02-14 02:53:00.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
It's not clear that doing -c config.json will create a config if one doesn't exist. We either should default to a config file (so blindly running the script Just Works) or be pedantic and force a generate flag
id: '12394'
key: BOTS-163
number: '163'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-02-14 02:53:00.0
votes: '0'
watches: '1'
workflowId: '12499'
---
actions: null

28
static/jira/browse/BOTS-164 Normal file
View file

@ -0,0 +1,28 @@
---
summary: We should clear out stale IRC bridge username/displaynames, as they pose problems for autocompletion
---
created: 2016-02-14 19:15:34.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12395'
key: BOTS-164
number: '164'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-02-14 19:20:16.0
votes: '0'
watches: '1'
workflowId: '12500'
---
actions:
- author: neb
body: 'By @matthew:matrix.org: specifically giving @freenode_ehuelsmann:matrix.org a sensible displayname would be appreciated by dcg'
created: 2016-02-14 19:20:16.0
id: '12611'
issue: '12395'
type: comment
updateauthor: neb
updated: 2016-02-14 19:20:16.0

30
static/jira/browse/BOTS-165 Normal file
View file

@ -0,0 +1,30 @@
---
summary: ircas cannot --generate-config because EADDRINUSE on ident service
---
created: 2016-02-16 15:31:29.0
creator: leonerd
description: ''
id: '12400'
key: BOTS-165
number: '165'
priority: '3'
project: '10101'
reporter: leonerd
resolution: '1'
resolutiondate: 2016-06-02 10:41:45.0
status: '5'
type: '1'
updated: 2016-06-02 10:41:45.0
votes: '0'
watches: '2'
workflowId: '12505'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/51
created: 2016-06-02 10:41:45.0
id: '12962'
issue: '12400'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:41:45.0

45
static/jira/browse/BOTS-166 Normal file
View file

@ -0,0 +1,45 @@
---
summary: ircas silently eats exceptions on console
---
created: 2016-02-16 15:33:07.0
creator: leonerd
description: |-
While attempting to generate registration file, the service was silently stopping before it created the file. Much debugging later found the problem to be BOTS-165. But that problem itself was obscured by the AS silently consuming errors. We eventually found that through bisection of throwing known exceptions and tracking it down to the line
{noformat}
--- a/lib/irc-appservice.js
+++ b/lib/irc-appservice.js
@@ -27,7 +27,7 @@ var dbConnPromise = null;
module.exports.configure = function(config) {
if (config.logging) {
logging.configure(config.logging);
- logging.setUncaughtExceptionLogger(log);
+ // logging.setUncaughtExceptionLogger(log);
}
if (config.statsd.hostname) {
stats.setEndpoint(config.statsd);
{noformat}
id: '12401'
key: BOTS-166
number: '166'
priority: '3'
project: '10101'
reporter: leonerd
resolution: '1'
resolutiondate: 2016-06-02 10:43:30.0
status: '5'
type: '1'
updated: 2016-06-02 10:43:30.0
votes: '0'
watches: '2'
workflowId: '12506'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/blob/develop/lib/main.js#L98
created: 2016-06-02 10:43:30.0
id: '12963'
issue: '12401'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:43:30.0

31
static/jira/browse/BOTS-167 Normal file
View file

@ -0,0 +1,31 @@
---
summary: IRC bridge 200 OKs transactions which have invalid HS token
---
assignee: kegan
created: 2016-02-16 17:05:02.0
creator: illicitonion
description: ''
id: '12402'
key: BOTS-167
number: '167'
priority: '3'
project: '10101'
reporter: illicitonion
resolution: '1'
resolutiondate: 2016-06-02 10:44:30.0
status: '5'
type: '1'
updated: 2016-06-02 10:44:30.0
votes: '0'
watches: '2'
workflowId: '12507'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/52
created: 2016-06-02 10:44:30.0
id: '12964'
issue: '12402'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:44:30.0

30
static/jira/browse/BOTS-168 Normal file
View file

@ -0,0 +1,30 @@
---
summary: m.call events going Matrix->IRC (or Slack etc) should be converted into matrix.to URLs (or vector.im URLs) to let non-Matrix users participate in calls
---
created: 2016-02-19 14:43:09.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12503'
key: BOTS-168
number: '168'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:44:54.0
status: '5'
type: '1'
updated: 2016-06-02 10:44:54.0
votes: '0'
watches: '2'
workflowId: '12603'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/47
created: 2016-06-02 10:44:54.0
id: '12965'
issue: '12503'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:44:54.0

22
static/jira/browse/BOTS-169 Normal file
View file

@ -0,0 +1,22 @@
---
summary: We could use a presence state for ASes to advertise when their remote users are inaccessible
---
created: 2016-02-19 16:43:19.0
creator: neb
description: |-
Submitted by @matthew:matrix.org
E.g. if there's an IRC netsplit, I'd expect the AS to warn that the presence of half its bridged IRC users has gone missing
id: '12506'
key: BOTS-169
number: '169'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-02-19 16:43:19.0
votes: '0'
watches: '1'
workflowId: '12606'
---
actions: null

74
static/jira/browse/BOTS-170 Normal file
View file

@ -0,0 +1,74 @@
---
summary: The IRC bridge crashes with a fatal error if it receives a 50x error
---
created: 2016-02-21 10:18:19.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12509'
key: BOTS-170
number: '170'
priority: '1'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 09:59:01.0
status: '6'
type: '1'
updated: 2016-06-02 09:59:01.0
votes: '0'
watches: '3'
workflowId: '12609'
---
actions:
- author: matthew
body: |-
This has been causing a world of pain over the last few days, since synapse was presumably deployed with some bug that cause sit to occasionally serve up 500s:
{code}
2016-02-20 21:05:34 ERROR:matrix-js-sdk PUT http://matrix.org/_matrix/client/api/v1/rooms/!XjCvwMSYaqGKTDOEmr%3Amatrix.org/send/m.room.message/m1456002320514 (@freenode_aaronpk:matrix.org) HTT
P 500 Error: undefined
2016-02-20 21:05:34 ERROR:main FATAL EXCEPTION
2016-02-20 21:05:34 ERROR:main TypeError: Cannot read property 'errcode' of undefined
at new MatrixError (/home/ircas/matrix-org/matrix-appservice-irc/node_modules/matrix-js-sdk/lib/http-api.js:384:29)
at /home/ircas/matrix-org/matrix-appservice-irc/node_modules/matrix-js-sdk/lib/http-api.js:352:19
at Request._callback (/home/ircas/matrix-org/matrix-appservice-irc/lib/mxlib/cs-extended-sdk.js:30:9)
at Request.self.callback (/home/ircas/matrix-org/matrix-appservice-irc/node_modules/request/request.js:199:22)
at emitTwo (events.js:87:13)
at Request.emit (events.js:172:7)
at Request.<anonymous> (/home/ircas/matrix-org/matrix-appservice-irc/node_modules/request/request.js:1036:10)
at emitOne (events.js:82:20)
at Request.emit (events.js:169:7)
at IncomingMessage.<anonymous> (/home/ircas/matrix-org/matrix-appservice-irc/node_modules/request/request.js:963:12)
{code}
Have tries to put a hot fix on /home/ircas/matrix-org/matrix-appservice-irc/node_modules/matrix-js-sdk/lib/http-api.js:384 for now, but this obviously needs to be fixed properly asap...
created: 2016-02-21 10:22:25.0
id: '12701'
issue: '12509'
type: comment
updateauthor: matthew
updated: 2016-02-21 10:22:25.0
- author: matthew
body: These look to have been 503s.
created: 2016-02-21 10:30:57.0
id: '12702'
issue: '12509'
type: comment
updateauthor: matthew
updated: 2016-02-21 10:30:57.0
- author: matthew
body: The hotfix seems superficially to have worked (but the bridge is still occasionally losing all state seemingly), so I've committed it to https://github.com/matrix-org/matrix-js-sdk/commit/363b08c4d8c71ba4f66c4a788032fb20350ea4ad. However this is clearly on entirely the wrong branch for the IRC AS; i have no idea where I should be committing it there :(
created: 2016-02-22 10:35:51.0
id: '12703'
issue: '12509'
type: comment
updateauthor: matthew
updated: 2016-02-22 10:35:51.0
- author: kegan
body: Fixed on `develop` branch of the IRC bridge because it deps on `matrix-appservice-bridge@0.3.5` which deps on `matrix-js-sdk@0.4.1` which is a version with that fix in it.
created: 2016-06-02 09:59:01.0
id: '12937'
issue: '12509'
type: comment
updateauthor: kegan
updated: 2016-06-02 09:59:01.0

38
static/jira/browse/BOTS-171 Normal file
View file

@ -0,0 +1,38 @@
---
summary: bridge relayed irc->matrix pm to Levans as an invite but the actual msg only appeared after a HS restart
---
created: 2016-02-22 14:18:51.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12513'
key: BOTS-171
number: '171'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:46:05.0
status: '5'
type: '1'
updated: 2016-06-02 10:46:05.0
votes: '0'
watches: '2'
workflowId: '12613'
---
actions:
- author: neb
body: 'By @matthew:matrix.org: This is with a remote HS, but using the matrix.org irc bridge'
created: 2016-02-22 14:31:48.0
id: '12704'
issue: '12513'
type: comment
updateauthor: neb
updated: 2016-02-22 14:31:48.0
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/53
created: 2016-06-02 10:46:05.0
id: '12966'
issue: '12513'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:46:05.0

30
static/jira/browse/BOTS-172 Normal file
View file

@ -0,0 +1,30 @@
---
summary: IRC->Matrix HTML tags went missing on $145376423162040dSrhV:matrix.org
---
created: 2016-02-23 13:25:01.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12519'
key: BOTS-172
number: '172'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:48:27.0
status: '5'
type: '1'
updated: 2016-06-02 10:48:27.0
votes: '0'
watches: '2'
workflowId: '12619'
---
actions:
- author: kegan
body: Fixed on `develop`
created: 2016-06-02 10:48:27.0
id: '12967'
issue: '12519'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:48:27.0

30
static/jira/browse/BOTS-173 Normal file
View file

@ -0,0 +1,30 @@
---
summary: IRC AS honours errant m.room.topic events sent as non-state events, when surely it should only honour them if state events.
---
created: 2016-02-27 15:47:48.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12529'
key: BOTS-173
number: '173'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:49:41.0
status: '5'
type: '1'
updated: 2016-06-02 10:49:41.0
votes: '0'
watches: '2'
workflowId: '12629'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/54
created: 2016-06-02 10:49:41.0
id: '12968'
issue: '12529'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:49:41.0

31
static/jira/browse/BOTS-174 Normal file
View file

@ -0,0 +1,31 @@
---
summary: 'bridge #gsoc:matrix.org to #matrix-gsoc on freenode and add it to our gsoc profile'
---
assignee: kegan
created: 2016-03-02 10:07:59.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12539'
key: BOTS-174
number: '174'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-03-02 16:18:41.0
status: '5'
type: '1'
updated: 2016-03-02 16:18:41.0
votes: '0'
watches: '2'
workflowId: '12639'
---
actions:
- author: kegan
body: Mapping made; will be picked up on next restart.
created: 2016-03-02 16:18:41.0
id: '12735'
issue: '12539'
type: comment
updateauthor: kegan
updated: 2016-03-02 16:18:41.0

349
static/jira/browse/BOTS-175 Normal file
View file

@ -0,0 +1,349 @@
---
summary: FreeSWITCH segfaults when we fail to detrickle ICE correctly in the verto bridge because HS->AS transactions can get in the wrong order
---
assignee: kegan
created: 2016-03-03 18:13:55.0
creator: matthew
description: |-
I suspect the failure to detrickle also causes calls to intermittently fail entirely.
The segfaults look like this:
{code}
(gdb) bt
#0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:260
#1 0x00007fa92549fc8d in switch_core_media_activate_rtp (session=0x7fa90c021d08) at src/switch_core_media.c:6251
#2 0x00007fa915fab758 in verto_tech_media (tech_pvt=0x7fa90c101a30, r_sdp=<optimized out>, sdp_type=<optimized out>) at mod_verto.c:2240
#3 verto_tech_media (tech_pvt=0x7fa90c101a30, r_sdp=<optimized out>, sdp_type=<optimized out>) at mod_verto.c:2223
#4 0x00007fa915fab82b in verto_media (session=0x7fa90c021d08) at mod_verto.c:2418
#5 verto_send_media_indication (session=session@entry=0x7fa90c021d08, method=method@entry=0x7fa915fae975 "verto.answer") at mod_verto.c:2465
#6 0x00007fa915fabb14 in messagehook (session=0x7fa90c021d08, msg=0x7fa907711770) at mod_verto.c:2535
#7 0x00007fa925478f84 in switch_core_session_perform_receive_message (session=0x7fa90c021d08, message=message@entry=0x7fa907711770, file=file@entry=0x7fa915661ec0 "mod_dptools.c", func=func@entry=0x7fa915666440 "answer_function", line=line@entry=1309)
at src/switch_core_session.c:868
{code}
...which looks like a null dereference somewhere in...
{code}
if (a_engine->rtcp_mux > 0 && !strcmp(a_engine->ice_in.cands[a_engine->ice_in.chosen[1]][1].con_addr, a_engine->ice_in.cands[a_engine->ice_in.chosen[0]][0].con_addr)
&& a_engine->ice_in.cands[a_engine->ice_in.chosen[1]][1].con_port == a_engine->ice_in.cands[a_engine->ice_in.chosen[0]][0].con_port) {
{code}
when processing ICE candiates and seeing mismatched RTP and RTCP candidates.
Meanwhile, the call that crashes it from Firefox has 1 call invite + 3 candidates:
{code}
v=0
o=mozilla...THIS_IS_SDPARTA-44.0.2 4365088332289342396 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 18:DB:29:E6:C7:44:2F:A2:AC:BE:3E:1A:CF:25:5C:7A:E1:0A:DF:32:9D:E5:18:86:95:87:26:4A:9E:DF:A0:2E
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ice-pwd:d26dbfc021a5dfb67816d801da818f05
a=ice-ufrag:4fccd89f
a=mid:sdparta_0
a=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {9f8599b3-278e-4437-8384-3731ca8461be}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=setup:actpass
a=ssrc:1692995449 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}
m=video 9 UDP/TLS/RTP/SAVPF 120 126 97
c=IN IP4 0.0.0.0
a=sendrecv
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=ice-pwd:d26dbfc021a5dfb67816d801da818f05
a=ice-ufrag:4fccd89f
a=mid:sdparta_1
a=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {0568f1d6-f329-4eb2-9907-0c5b44d4c74c}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:916254511 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}
{code}
and then:
{code}
{"candidate":"candidate:0 1 UDP 2122252543 131.254.15.55 53897 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},
{"candidate":"candidate:3 1 UDP 2122187007 172.17.42.1 40522 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},
{"candidate":"candidate:0 2 UDP 2122252542 131.254.15.55 59712 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},
{"candidate":"candidate:3 2 UDP 2122187006 172.17.42.1 33823 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},
{"candidate":"candidate:0 1 UDP 2122252543 131.254.15.55 36311 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},
{"candidate":"candidate:3 1 UDP 2122187007 172.17.42.1 59697 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},
{"candidate":"candidate:0 2 UDP 2122252542 131.254.15.55 48094 typ host", "sdpMLineIndex":1,"sdpMid":"sdparta_1"},
{"candidate":"candidate:3 2 UDP 2122187006 172.17.42.1 46496 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"}
{code}
and then:
{code}
{"candidate":"candidate:7 1 UDP 8265727 83.166.68.175 57250 typ relay raddr 83.166.68.175 rport 57250","sdpMLineIndex":0,"sdpMid":"sdparta_0"}
{"candidate":"candidate:6 2 UDP 8331262 83.166.68.175 62268 typ relay raddr 83.166.68.175 rport 62268","sdpMLineIndex":0,"sdpMid":"sdparta_0"}
{code}
and finally:
{code}
{"candidate":"candidate:7 2 UDP 8265726 83.166.68.175 51145 typ relay raddr 83.166.68.175 rport 51145","sdpMLineIndex":0,"sdpMid":"sdparta_0"},
{"candidate":"candidate:6 1 UDP 8331263 83.166.68.175 58486 typ relay raddr 83.166.68.175 rport 58486","sdpMLineIndex":1,"sdpMid":"sdparta_1"},
{"candidate":"candidate:7 1 UDP 8265727 83.166.68.175 62629 typ relay raddr 83.166.68.175 rport 62629","sdpMLineIndex":1,"sdpMid":"sdparta_1"},
{"candidate":"candidate:7 2 UDP 8265726 83.166.68.175 54898 typ relay raddr 83.166.68.175 rport 54898","sdpMLineIndex":1,"sdpMid":"sdparta_1"}
{code}
The problem is that these events, despite having the right stream & topological ordering in the events table in synapse, get delivered to the AS in the wrong order; the invite gets sent after the first two candidates.
As a result, the AS ignores the first two candidates... and then gathers the final candidate onto the invite. In this instance, this means that the SDP sent to the freeswitch looks like this:
{code}
v=0
o=mozilla...THIS_IS_SDPARTA-44.0.2 4365088332289342396 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 18:DB:29:E6:C7:44:2F:A2:AC:BE:3E:1A:CF:25
:5C:7A:E1:0A:DF:32:9D:E5:18:86:95:87:26:4A:9E:DF:A0:2E
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8
c=IN IP4 10.10.10.10
a=candidate:7 2 UDP 8265726 83.166.68.175 51145 typ relay raddr 83.166.68.175 rport 51145
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ice-pwd:d26dbfc021a5dfb67816d801da818f05
a=ice-ufrag:4fccd89f
a=mid:sdparta_0
a=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {9f8599b3-278e-4437-8384-3731ca8461be}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=setup:actpass
a=ssrc:1692995449 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}
m=video 9 UDP/TLS/RTP/SAVPF 120 126 97
c=IN IP4 10.10.10.10
a=candidate:7 2 UDP 8265726 83.166.68.175 54898 typ relay raddr 83.166.68.175 rport 54898
a=candidate:7 1 UDP 8265727 83.166.68.175 62629 typ relay raddr 83.166.68.175 rport 62629
a=candidate:6 1 UDP 8331263 83.166.68.175 58486 typ relay raddr 83.166.68.175 rport 58486
a=sendrecv
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=ice-pwd:d26dbfc021a5dfb67816d801da818f05
a=ice-ufrag:4fccd89f
a=mid:sdparta_1
a=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {0568f1d6-f329-4eb2-9907-0c5b44d4c74c}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:916254511 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}
{code}
...and the mismatched RTP/RTCP candidates are sufficient to segfault FS.
Two problems:
* Synapse absolutely shouldn't be sending the events out of order
* AS should gather the ICE correctly:
* It should never forward incomplete candidate pairs
* It shouldn't drop candidates received before an INVITE
* The current metric for finishing gathering (we have seen relay or srflx candidates) is insufficient - we should prolly wait for the host candidates too at the least.
id: '12541'
key: BOTS-175
number: '175'
priority: '1'
project: '10101'
reporter: matthew
status: '1'
type: '1'
updated: 2016-03-04 18:23:35.0
votes: '1'
watches: '1'
workflowId: '12641'
---
actions:
- author: matthew
body: |-
Kegan asked for more details of the ordering problem:
an excerpt of:
{code}
select * from events where room_id='!UsoNWsdlSGAQJwEUdp:matrix.org' order by stream_ordering;
{code}
shows the invite + 3 candidates in the right order...
{code}
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
stream_ordering | 14340016
topological_ordering | 8
event_id | $1456995870352529KGLcY:matrix.org
type | m.call.invite
room_id | !UsoNWsdlSGAQJwEUdp:matrix.org
content | {"call_id":"c1456995863946","lifetime":60000,"offer":{"sdp":"v=0\r\no=mozilla...THIS_IS_SDPARTA-44.0.2 4365088332289342396 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=sendrecv\r\na=fingerprint:sha-256 18:DB:29:E6:C7:44:2F:A2:AC:BE:3E:1A:CF:25:5C:7A:E1:0
A:DF:32:9D:E5:18:86:95:87:26:4A:9E:DF:A0:2E\r\na=group:BUNDLE sdparta_0 sdparta_1\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=
ice-pwd:d26dbfc021a5dfb67816d801da818f05\r\na=ice-ufrag:4fccd89f\r\na=mid:sdparta_0\r\na=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {9f8599b3-278e-4437-8384-3731ca8461be}\r\na=rtcp-mux\r\na=rtpmap:109 opus/48000/2\r\na=rtpmap:9 G722/8000/1\r\na=rtpmap:0 PCMU/8000\r\na=
rtpmap:8 PCMA/8000\r\na=setup:actpass\r\na=ssrc:1692995449 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}\r\nm=video 9 UDP/TLS/RTP/SAVPF 120 126 97\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=
fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=ice-pwd:d26dbfc021a5dfb67816d801da818f05\r\na=ice-ufrag:4fccd89f\r\na=mid:sdparta_1\r\na=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {0568f1d6-f329-4eb2-9907-0c5b44d4c74c
}\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=rtpmap:120 VP8/90000\r\na=rtpmap:
126 H264/90000\r\na=rtpmap:97 H264/90000\r\na=setup:actpass\r\na=ssrc:916254511 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}\r\n","type":"offer"},"version":0}
unrecognized_keys |
processed | t
outlier | f
depth | 8
origin_server_ts | 1456995870852
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
stream_ordering | 14340017
topological_ordering | 9
event_id | $1456995870352530pSsSe:matrix.org
type | m.call.candidates
room_id | !UsoNWsdlSGAQJwEUdp:matrix.org
content | {"call_id":"c1456995863946","candidates":[{"candidate":"candidate:0 1 UDP 2122252543 131.254.15.55 53897 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:3 1 UDP 2122187007 172.17.42.1 40522 typ host","sdpMLineIndex":0,"sd
pMid":"sdparta_0"},{"candidate":"candidate:0 2 UDP 2122252542 131.254.15.55 59712 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:3 2 UDP 2122187006 172.17.42.1 33823 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:0 1
UDP 2122252543 131.254.15.55 36311 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:3 1 UDP 2122187007 172.17.42.1 59697 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:0 2 UDP 2122252542 131.254.15.55 48094 typ host",
"sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:3 2 UDP 2122187006 172.17.42.1 46496 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"}],"version":0}
unrecognized_keys |
processed | t
outlier | f
depth | 9
origin_server_ts | 1456995870977
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
stream_ordering | 14340018
topological_ordering | 10
event_id | $1456995871352531EgUvI:matrix.org
type | m.call.candidates
room_id | !UsoNWsdlSGAQJwEUdp:matrix.org
content | {"call_id":"c1456995863946","candidates":[{"candidate":"candidate:7 1 UDP 8265727 83.166.68.175 57250 typ relay raddr 83.166.68.175 rport 57250","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:6 2 UDP 8331262 83.166.68.175 62268 ty
p relay raddr 83.166.68.175 rport 62268","sdpMLineIndex":0,"sdpMid":"sdparta_0"}],"version":0}
unrecognized_keys |
processed | t
outlier | f
depth | 10
origin_server_ts | 1456995871093
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
stream_ordering | 14340019
topological_ordering | 11
event_id | $1456995871352532nXqva:matrix.org
type | m.call.candidates
room_id | !UsoNWsdlSGAQJwEUdp:matrix.org
content | {"call_id":"c1456995863946","candidates":[{"candidate":"candidate:7 2 UDP 8265726 83.166.68.175 51145 typ relay raddr 83.166.68.175 rport 51145","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:6 1 UDP 8331263 83.166.68.175 58486 ty
p relay raddr 83.166.68.175 rport 58486","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:7 1 UDP 8265727 83.166.68.175 62629 typ relay raddr 83.166.68.175 rport 62629","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:7 2 UDP 8265726 83.166
.68.175 54898 typ relay raddr 83.166.68.175 rport 54898","sdpMLineIndex":1,"sdpMid":"sdparta_1"}],"version":0}
unrecognized_keys |
processed | t
outlier | f
depth | 11
origin_server_ts | 1456995871450
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{code}
...meanwhile the logfile on the AS shows:
{code}
83.166.68.251 - - [03/Mar/2016:09:04:25 +0000] "PUT /transactions/13874?access_token=91a0ed7ddb6555ee27d3a17c3d87b72547b5ba0330b159e864a8c63b51108840 HTTP/1.1" 200 2 "-" "Synapse/0.13.3 (b=develop,e8d34bc)"
83.166.68.251 - - [03/Mar/2016:09:04:31 +0000] "PUT /transactions/13875?access_token=supersecret HTTP/1.1" 200 2 "-" "Synapse/0.13.3 (b=develop,e8d34bc)"
Call candidates: room=!UsoNWsdlSGAQJwEUdp:matrix.org member=@xxx:matrix.org content={"call_id":"c1456995863946","candidates":[{"candidate":"candidate:0 1 UDP 2122252543 131.254.15.55 53897 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candid
ate:3 1 UDP 2122187007 172.17.42.1 40522 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:0 2 UDP 2122252542 131.254.15.55 59712 typ host","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:3 2 UDP 2122187006 172.17.42.1 33823 typ h
ost","sdpMLineIndex":0,"sdpMid":"sdparta_0"},{"candidate":"candidate:0 1 UDP 2122252543 131.254.15.55 36311 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:3 1 UDP 2122187007 172.17.42.1 59697 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{
"candidate":"candidate:0 2 UDP 2122252542 131.254.15.55 48094 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:3 2 UDP 2122187006 172.17.42.1 46496 typ host","sdpMLineIndex":1,"sdpMid":"sdparta_1"}],"version":0}
[8nqunpclewgsk] Handling request
[8nqunpclewgsk] FAILED (6ms) 'Received candidates for unknown call'
83.166.68.251 - - [03/Mar/2016:09:04:31 +0000] "PUT /transactions/13876?access_token=supersecret HTTP/1.1" 200 2 "-" "Synapse/0.13.3 (b=develop,e8d34bc)"
Call candidates: room=!UsoNWsdlSGAQJwEUdp:matrix.org member=@xxx:matrix.org content={"call_id":"c1456995863946","candidates":[{"candidate":"candidate:7 1 UDP 8265727 83.166.68.175 57250 typ relay raddr 83.166.68.175 rport 57250","sdpMLineIndex":0,"sdpMid":"sd
parta_0"},{"candidate":"candidate:6 2 UDP 8331262 83.166.68.175 62268 typ relay raddr 83.166.68.175 rport 62268","sdpMLineIndex":0,"sdpMid":"sdparta_0"}],"version":0}
[f37u1j24qk0s8] Handling request
[f37u1j24qk0s8] FAILED (15ms) 'Received candidates for unknown call'
Call invite: room=!UsoNWsdlSGAQJwEUdp:matrix.org member=@xxx:matrix.org content={"call_id":"c1456995863946","lifetime":60000,"offer":{"sdp":"v=0\r\no=mozilla...THIS_IS_SDPARTA-44.0.2 4365088332289342396 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=sendrecv\r\na=fing
erprint:sha-256 18:DB:29:E6:C7:44:2F:A2:AC:BE:3E:1A:CF:25:5C:7A:E1:0A:DF:32:9D:E5:18:86:95:87:26:4A:9E:DF:A0:2E\r\na=group:BUNDLE sdparta_0 sdparta_1\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8\r\nc=IN IP4 0.0.0.0\r\na=send
recv\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=ice-pwd:d26dbfc021a5dfb67816d801da818f05\r\na=ice-ufrag:4fccd89f\r\na=mid:sdparta_0\r\na=msid:{01d2845f-c296-4d1a-a9ca-0d993a70589b} {9f8599b3-278e-4437-8384-3731ca8461be}\r\na=rtcp-mux\r\na=rtpmap:109
opus/48000/2\r\na=rtpmap:9 G722/8000/1\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=setup:actpass\r\na=ssrc:1692995449 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}\r\nm=video 9 UDP/TLS/RTP/SAVPF 120 126 97\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=fmtp:126 profile-
level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=ice-pwd:d26dbfc021a5dfb67816d801da818f05\r\na=ice-ufrag:4fccd89f\r\na=mid:sdparta_1\r\na=msid:{01d2845
f-c296-4d1a-a9ca-0d993a70589b} {0568f1d6-f329-4eb2-9907-0c5b44d4c74c}\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtc
p-fb:97 ccm fir\r\na=rtcp-mux\r\na=rtpmap:120 VP8/90000\r\na=rtpmap:126 H264/90000\r\na=rtpmap:97 H264/90000\r\na=setup:actpass\r\na=ssrc:916254511 cname:{f187f95c-da34-4c11-998b-d5527ae10c1e}\r\n","type":"offer"},"version":0}
[8bcerq60vn4sg] Handling request
[-] GET https://matrix.org/_matrix/client/api/v1/rooms/!ebYRNcfIShCeAsFkRY%3Amatrix.org/state (@fs_IWViWVJOY2ZJU2hDZUFzRmtSWTptYXRyaXgub3Jn:matrix.org) Body:
[-] GET https://matrix.org/_matrix/client/api/v1/rooms/!ebYRNcfIShCeAsFkRY%3Amatrix.org/state (@fs_IWViWVJOY2ZJU2hDZUFzRmtSWTptYXRyaXgub3Jn:matrix.org) HTTP 200 [{"origin_server_ts":1456937009869,"sender":"@yyy:matrix.org","event_id":"
Add matrix side for fs_user @fs_IWViWVJOY2ZJU2hDZUFzRmtSWTptYXRyaXgub3Jn:matrix.org (@xxx:matrix.org)
Storing verto call on ext=3504 fs_user=@fs_IWViWVJOY2ZJU2hDZUFzRmtSWTptYXRyaXgub3Jn:matrix.org matrix_users=2
[8bcerq60vn4sg] SUCCESS (421ms) undefined
83.166.68.251 - - [03/Mar/2016:09:04:32 +0000] "PUT /transactions/13877?access_token=supersecret HTTP/1.1" 200 2 "-" "Synapse/0.13.3 (b=develop,e8d34bc)"
Call candidates: room=!UsoNWsdlSGAQJwEUdp:matrix.org member=@xxx:matrix.org content={"call_id":"c1456995863946","candidates":[{"candidate":"candidate:7 2 UDP 8265726 83.166.68.175 51145 typ relay raddr 83.166.68.175 rport 51145","sdpMLineIndex":0,"sdpMid":"sd
parta_0"},{"candidate":"candidate:6 1 UDP 8331263 83.166.68.175 58486 typ relay raddr 83.166.68.175 rport 58486","sdpMLineIndex":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:7 1 UDP 8265727 83.166.68.175 62629 typ relay raddr 83.166.68.175 rport 62629","sdpMLineIndex
":1,"sdpMid":"sdparta_1"},{"candidate":"candidate:7 2 UDP 8265726 83.166.68.175 54898 typ relay raddr 83.166.68.175 rport 54898","sdpMLineIndex":1,"sdpMid":"sdparta_1"}],"version":0}
Gathered enough candidates for c1456995863946
index=0 - m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8
Inserted candidate candidate:7 2 UDP 8265726 83.166.68.175 51145 typ relay raddr 83.166.68.175 rport 51145 at m= index 0
index=1 - m=video 9 UDP/TLS/RTP/SAVPF 120 126 97
Inserted candidate candidate:6 1 UDP 8331263 83.166.68.175 58486 typ relay raddr 83.166.68.175 rport 58486 at m= index 1
Inserted candidate candidate:7 1 UDP 8265727 83.166.68.175 62629 typ relay raddr 83.166.68.175 rport 62629 at m= index 1
Inserted candidate candidate:7 2 UDP 8265726 83.166.68.175 54898 typ relay raddr 83.166.68.175 rport 54898 at m= index 1
{code}
...i.e. 2 of the candidates are received before the invite.
created: 2016-03-04 18:07:33.0
id: '12750'
issue: '12541'
type: comment
updateauthor: matthew
updated: 2016-03-04 18:11:26.0
- author: matthew
body: actually I guess another possibility is that the AS responded to these transactions out of order, given we can't see which transaction matches which event. In general I assume ASes should be able to handle out-of-order events anyway... or are transaction IDs meant to given a guaranteed ordering?
created: 2016-03-04 18:12:12.0
id: '12751'
issue: '12541'
type: comment
updateauthor: matthew
updated: 2016-03-04 18:12:12.0
- author: matthew
body: |-
This doesn't coincide with any server restarts - the first one that day was
{code}
2016-03-03 13:47:00,396 - synapse.app.homeserver - 196 - INFO - - Synapse now listening on port 8448
{code}
created: 2016-03-04 18:23:35.0
id: '12752'
issue: '12541'
type: comment
updateauthor: matthew
updated: 2016-03-04 18:23:35.0

20
static/jira/browse/BOTS-176 Normal file
View file

@ -0,0 +1,20 @@
---
summary: If an AS goes offline it takes ages for the HS to notice it again, and then the HS DoSes it
---
created: 2016-03-04 18:55:39.0
creator: matthew
description: ''
id: '12546'
key: BOTS-176
number: '176'
priority: '1'
project: '10101'
reporter: matthew
status: '1'
type: '1'
updated: 2016-03-04 18:55:39.0
votes: '0'
watches: '1'
workflowId: '12646'
---
actions: null

30
static/jira/browse/BOTS-177 Normal file
View file

@ -0,0 +1,30 @@
---
summary: IRC bridge mangles HTML URLs from markdown
---
created: 2016-03-05 18:13:31.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12547'
key: BOTS-177
number: '177'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:49:57.0
status: '5'
type: '1'
updated: 2016-06-02 10:49:57.0
votes: '0'
watches: '2'
workflowId: '12647'
---
actions:
- author: kegan
body: Fixed on `develop`
created: 2016-06-02 10:49:57.0
id: '12969'
issue: '12547'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:49:57.0

20
static/jira/browse/BOTS-178 Normal file
View file

@ -0,0 +1,20 @@
---
summary: We should finish our HipChat bridge...
---
created: 2016-03-07 20:56:40.0
creator: neb
description: Submitted by @matthew:matrix.org
id: '12549'
key: BOTS-178
number: '178'
priority: '3'
project: '10101'
reporter: neb
status: '1'
type: '1'
updated: 2016-03-07 20:56:40.0
votes: '0'
watches: '1'
workflowId: '12649'
---
actions: null

23
static/jira/browse/BOTS-179 Normal file
View file

@ -0,0 +1,23 @@
---
summary: NEB asks for JIRA URL on startup if not set
---
created: 2016-03-12 17:51:04.0
creator: gergelypolonkai
description: |-
If jira.json doesn't have a url key, NEB asks for one with raw_input. However, the on-screen logs cover the input message, and raw_input blocks the bot from starting, which is not very machine-friendly.
It should either fail to start (with a proper error message), or the JIRA plugin should automagically disable itself if the URL is not present.
id: '12554'
key: BOTS-179
number: '179'
priority: '3'
project: '10101'
reporter: gergelypolonkai
status: '1'
type: '1'
updated: 2016-03-12 17:51:04.0
votes: '0'
watches: '1'
workflowId: '12654'
---
actions: null

20
static/jira/browse/BOTS-18 Normal file
View file

@ -0,0 +1,20 @@
---
summary: 'IRC: Handle m.{file,audio,video} analogously to m.image'
---
created: 2015-02-16 19:59:05.0
creator: leonerd
description: ''
id: '11078'
key: BOTS-18
number: '18'
priority: '3'
project: '10101'
reporter: leonerd
status: '1'
type: '1'
updated: 2016-01-04 15:37:50.0
votes: '0'
watches: '1'
workflowId: '11178'
---
actions: null

30
static/jira/browse/BOTS-180 Normal file
View file

@ -0,0 +1,30 @@
---
summary: Report prometheus stats for irc joins/parts
---
created: 2016-03-17 11:27:15.0
creator: matthew
description: ''
id: '12562'
key: BOTS-180
number: '180'
priority: '1'
project: '10101'
reporter: matthew
resolution: '10000'
resolutiondate: 2016-06-02 09:37:36.0
status: '6'
type: '1'
updated: 2016-06-02 09:37:36.0
votes: '0'
watches: '2'
workflowId: '12662'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/35
created: 2016-06-02 09:37:36.0
id: '12936'
issue: '12562'
type: comment
updateauthor: kegan
updated: 2016-06-02 09:37:36.0

40
static/jira/browse/BOTS-181 Normal file
View file

@ -0,0 +1,40 @@
---
summary: Undismissable invitations via IRC bridges
---
created: 2016-03-19 18:41:36.0
creator: richvdh
description: |-
From Dusk in HQ:
{noformat}
Cae and I had IRC bridges running
I was connected to rooms using mine
and he invited me to rooms on his
those invites resulted in failed connections to the IRC Network
because of that I had 22 notifications from INFOSERV
that I couldn't get rid of
{noformat}
id: '12567'
key: BOTS-181
number: '181'
priority: '3'
project: '10101'
reporter: richvdh
resolution: '3'
resolutiondate: 2016-03-19 19:06:24.0
status: '5'
type: '1'
updated: 2016-03-19 19:06:24.0
votes: '0'
watches: '1'
workflowId: '12667'
---
actions:
- author: richvdh
body: Actually this looks exactly like SYN-657 so in the absence of evidence to the contrary, let's start there
created: 2016-03-19 19:06:03.0
id: '12768'
issue: '12567'
type: comment
updateauthor: richvdh
updated: 2016-03-19 19:06:03.0

40
static/jira/browse/BOTS-182 Normal file
View file

@ -0,0 +1,40 @@
---
summary: 'IRC AS: Support /whois in the admin room'
---
created: 2016-04-12 10:04:57.0
creator: neb
description: |-
Submitted by @kegan:matrix.org
This is specifically so users can check to see if the IRC user they want to speak to is online, given we can't do member list syncing I->M
id: '12620'
key: BOTS-182
number: '182'
priority: '3'
project: '10101'
reporter: neb
resolution: '1'
resolutiondate: 2016-06-02 10:37:27.0
status: '5'
type: '1'
updated: 2016-06-08 04:32:18.0
votes: '0'
watches: '3'
workflowId: '12720'
---
actions:
- author: kegan
body: https://github.com/matrix-org/matrix-appservice-irc/issues/50
created: 2016-06-02 10:37:27.0
id: '12959'
issue: '12620'
type: comment
updateauthor: kegan
updated: 2016-06-02 10:37:27.0
- author: rryan
body: This is marked resolved but based on reading the code I don't believe it is -- does that mean someone has done this but it's not merged to master yet? I'd like to contribute a fix here if nobody else is working on it!
created: 2016-06-08 04:32:18.0
id: '12992'
issue: '12620'
type: comment
updateauthor: rryan
updated: 2016-06-08 04:32:18.0

22
static/jira/browse/BOTS-183 Normal file
View file

@ -0,0 +1,22 @@
---
summary: Test issue creation
---
created: 2016-05-23 10:56:26.0
creator: kegan
description: ''
id: '12672'
key: BOTS-183
number: '183'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-23 10:56:59.0
status: '6'
type: '1'
updated: 2016-05-23 10:56:59.0
votes: '0'
watches: '1'
workflowId: '12772'
---
actions: null

22
static/jira/browse/BOTS-184 Normal file
View file

@ -0,0 +1,22 @@
---
summary: this is a test
---
created: 2016-05-24 16:57:08.0
creator: kegan
description: ''
id: '12676'
key: BOTS-184
number: '184'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-24 16:58:22.0
status: '6'
type: '1'
updated: 2016-05-24 16:58:22.0
votes: '0'
watches: '1'
workflowId: '12776'
---
actions: null

22
static/jira/browse/BOTS-185 Normal file
View file

@ -0,0 +1,22 @@
---
summary: this is another test
---
created: 2016-05-24 16:58:06.0
creator: kegan
description: ''
id: '12677'
key: BOTS-185
number: '185'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-24 16:58:27.0
status: '6'
type: '1'
updated: 2016-05-24 16:58:27.0
votes: '0'
watches: '1'
workflowId: '12777'
---
actions: null

22
static/jira/browse/BOTS-186 Normal file
View file

@ -0,0 +1,22 @@
---
summary: test
---
created: 2016-05-25 10:55:25.0
creator: kegan
description: ''
id: '12678'
key: BOTS-186
number: '186'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-25 10:59:05.0
status: '6'
type: '1'
updated: 2016-05-25 10:59:05.0
votes: '0'
watches: '1'
workflowId: '12778'
---
actions: null

22
static/jira/browse/BOTS-187 Normal file
View file

@ -0,0 +1,22 @@
---
summary: this is another test2
---
created: 2016-05-25 10:58:08.0
creator: kegan
description: ''
id: '12679'
key: BOTS-187
number: '187'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-25 10:59:01.0
status: '6'
type: '1'
updated: 2016-05-25 10:59:01.0
votes: '0'
watches: '1'
workflowId: '12779'
---
actions: null

22
static/jira/browse/BOTS-188 Normal file
View file

@ -0,0 +1,22 @@
---
summary: this is another test3
---
created: 2016-05-25 10:58:31.0
creator: kegan
description: ''
id: '12680'
key: BOTS-188
number: '188'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-25 10:58:57.0
status: '6'
type: '1'
updated: 2016-05-25 10:58:57.0
votes: '0'
watches: '1'
workflowId: '12780'
---
actions: null

22
static/jira/browse/BOTS-189 Normal file
View file

@ -0,0 +1,22 @@
---
summary: test
---
created: 2016-05-27 11:13:28.0
creator: kegan
description: ''
id: '12681'
key: BOTS-189
number: '189'
priority: '3'
project: '10101'
reporter: kegan
resolution: '1'
resolutiondate: 2016-05-27 11:14:06.0
status: '6'
type: '1'
updated: 2016-05-27 11:14:06.0
votes: '0'
watches: '1'
workflowId: '12781'
---
actions: null

22
static/jira/browse/BOTS-19 Normal file
View file

@ -0,0 +1,22 @@
---
summary: IRC bridge should part IRC users when they leave the room
---
created: 2015-02-18 22:16:28.0
creator: matthew
description: ''
id: '11091'
key: BOTS-19
number: '19'
priority: '2'
project: '10101'
reporter: matthew
resolution: '1'
resolutiondate: 2015-05-12 16:55:16.0
status: '5'
type: '2'
updated: 2015-08-27 23:59:01.0
votes: '0'
watches: '1'
workflowId: '11191'
---
actions: null

Some files were not shown because too many files have changed in this diff Show more