forked from cadence/out-of-your-element
Compare commits
2 commits
81bf0b935f
...
3a74dfb78f
| Author | SHA1 | Date | |
|---|---|---|---|
| 3a74dfb78f | |||
| f17c070175 |
1 changed files with 15 additions and 4 deletions
|
|
@ -225,8 +225,19 @@ async event => {
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
const messageResponses = await sendEvent.sendEvent(event)
|
try {
|
||||||
if (!messageResponses.length) return
|
const messageResponses = await sendEvent.sendEvent(event)
|
||||||
|
if (!messageResponses.length) return
|
||||||
|
}
|
||||||
|
catch (e){ //This had to have been caught outside the regular guard()->sendError() loop, otherwise commands wouldn't get processed.
|
||||||
|
if (e.message?.includes("220001")) { //see: https://docs.discord.com/developers/topics/opcodes-and-status-codes
|
||||||
|
if(!event.content.body.startsWith("/thread")) api.sendEvent(event.room_id, "m.room.message", {
|
||||||
|
msgtype: "m.text",
|
||||||
|
body: "You cannot send regular messages in rooms bridged to forum channels! Please create a /thread instead."
|
||||||
|
})
|
||||||
|
}
|
||||||
|
else throw e
|
||||||
|
}
|
||||||
|
|
||||||
if (event.type === "m.room.message" && event.content.msgtype === "m.text" && processCommands) {
|
if (event.type === "m.room.message" && event.content.msgtype === "m.text" && processCommands) {
|
||||||
await matrixCommandHandler.parseAndExecute(
|
await matrixCommandHandler.parseAndExecute(
|
||||||
|
|
@ -256,7 +267,7 @@ async function bridgeThread(event) {
|
||||||
if (!messageID) return false; //Message not bridged? Too bad! Discord users will just see normal replies, and Matrix uses won't get a thread-room. We COULD technically create a "headless" thread on Discord side and bridge it to a new thread-room, but that comes with a whole host of complications on its own (notably: what do we do if the message gets bridged later (by reaction emoji), and then hypothetically gets its own thread; and: getThreadRoomFromThreadEvent will have to be much more complex than a simple DB call (probably a whole new DB table would have to be created, just to hold these Matrix-branched-but-headless-on-Discord threads) because the simple „MX event --(db)--> Discord Message --(Discord spec)--> Discord thread” relation would no longer hold true), which may not be worth it, as an unbridged message in a bridged channel is already an edge-case (so it seems pointless to introduce a whole bunch of edgier-cases that handling this edge-case "properly" would bring).
|
if (!messageID) return false; //Message not bridged? Too bad! Discord users will just see normal replies, and Matrix uses won't get a thread-room. We COULD technically create a "headless" thread on Discord side and bridge it to a new thread-room, but that comes with a whole host of complications on its own (notably: what do we do if the message gets bridged later (by reaction emoji), and then hypothetically gets its own thread; and: getThreadRoomFromThreadEvent will have to be much more complex than a simple DB call (probably a whole new DB table would have to be created, just to hold these Matrix-branched-but-headless-on-Discord threads) because the simple „MX event --(db)--> Discord Message --(Discord spec)--> Discord thread” relation would no longer hold true), which may not be worth it, as an unbridged message in a bridged channel is already an edge-case (so it seems pointless to introduce a whole bunch of edgier-cases that handling this edge-case "properly" would bring).
|
||||||
|
|
||||||
let name = event.content.body
|
let name = event.content.body
|
||||||
if (name.startsWith("/thread ")) name = name.substring(8);
|
if (name.startsWith("/thread ") && name.length > 8) name = name.substring(8);
|
||||||
else name = (await api.getEvent(event.room_id, eventID)).content.body;
|
else name = (await api.getEvent(event.room_id, eventID)).content.body;
|
||||||
name = name.length < 100 ? name.replaceAll("\n", " ") : name.slice(0, 96).replaceAll("\n", " ") + "..."
|
name = name.length < 100 ? name.replaceAll("\n", " ") : name.slice(0, 96).replaceAll("\n", " ") + "..."
|
||||||
|
|
||||||
|
|
@ -265,7 +276,7 @@ async function bridgeThread(event) {
|
||||||
return true;
|
return true;
|
||||||
}
|
}
|
||||||
catch (e){
|
catch (e){
|
||||||
if (e.message?.includes("50024")) return false; //Tried to created a thread in a thread (see: https://docs.discord.com/developers/topics/opcodes-and-status-codes)? Too bad! Discord users will just see normal replies, and Matrix uses won't get a thread-room. Same case as for message-not-bridged, except there at least exists a HYPOTHETICAL solution (just one so unwieldly that it's nonsensical to dedicate resources to), wheres here I don't know what could possibly be done at all.
|
if (e.message?.includes("50024")) return false; //Tried to created a thread in a thread? Too bad! Discord users will just see normal replies, and Matrix uses won't get a thread-room. Same case as for message-not-bridged, except there at least exists a HYPOTHETICAL solution (just one so unwieldly that it's nonsensical to dedicate resources to), wheres here I don't know what could possibly be done at all.
|
||||||
else throw e; //In here (unlike in matrix-command-handler.js), there are much fewer things that could "intentionally" go wrong (both thread double-creation and too-long names shouldn't be possible due to earlier checks). As such, if anything breaks, it should be reported to OOYE for further investigation, which the user should do when encountering an "ugly error" (if they follow the „every error should be reported” directive), so this is re-thrown as-is (no stacktrace-breaking exception wrapping) to be turned into such an "ugly error" upstream.
|
else throw e; //In here (unlike in matrix-command-handler.js), there are much fewer things that could "intentionally" go wrong (both thread double-creation and too-long names shouldn't be possible due to earlier checks). As such, if anything breaks, it should be reported to OOYE for further investigation, which the user should do when encountering an "ugly error" (if they follow the „every error should be reported” directive), so this is re-thrown as-is (no stacktrace-breaking exception wrapping) to be turned into such an "ugly error" upstream.
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue