WIP: feature: threads'n'forums #74
2 changed files with 12 additions and 21 deletions
|
|
@ -213,15 +213,12 @@ async event => {
|
|||
|
||||
let processCommands = true
|
||||
if (event.content["m.relates_to"]?.rel_type === "m.thread") {
|
||||
/**@type {string|null} */
|
||||
let toRedact = event.room_id
|
||||
const toRedact = event.room_id
|
||||
const bridgedTo = utils.getThreadRoomFromThreadEvent(event.content["m.relates_to"].event_id)
|
||||
processCommands = false
|
||||
|
||||
if (bridgedTo) event.room_id = bridgedTo;
|
||||
else if (!await bridgeThread(event)) toRedact = null;
|
||||
|
||||
if (toRedact) {
|
||||
else if (await bridgeThread(event)) {
|
||||
api.redactEvent(toRedact, event.event_id)
|
||||
event.content["m.relates_to"] = undefined
|
||||
api.sendEvent(event.room_id, event.type, {...event.content, body: event.content.body+"\n ~ "+event.sender, formatted_body: event.content.formatted_body ? event.content.formatted_body+"<br> ~ "+event.sender :undefined })
|
||||
|
|
@ -263,8 +260,14 @@ async function bridgeThread(event) {
|
|||
else name = (await api.getEvent(event.room_id, eventID)).content.body;
|
||||
name = name.length < 100 ? name.replaceAll("\n", " ") : name.slice(0, 96).replaceAll("\n", " ") + "..."
|
||||
|
||||
try {
|
||||
event.room_id = await createRoom.ensureRoom((await discord.snow.channel.createThreadWithMessage(channelID, messageID, {name})).id)
|
||||
return true;
|
||||
}
|
||||
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.
|
||||
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.
|
||||
}
|
||||
}
|
||||
|
||||
sync.addTemporaryListener(as, "type:m.sticker", guard("m.sticker",
|
||||
|
|
|
|||
|
|
@ -299,14 +299,7 @@ const commands = [{
|
|||
let err = e.message // see: https://docs.discord.com/developers/topics/opcodes-and-status-codes
|
||||
|
||||
if (err?.includes("160004")) {
|
||||
if (isFallingBack){
|
||||
await api.sendEvent(event.room_id, "m.room.message", {
|
||||
...ctx,
|
||||
msgtype: "m.text",
|
||||
body: "⚠️ Discord claims that there already exists a thread for the message you ran this command on, but that doesn't make logical sense, as it doesn't seem like you ran this command on any message. Either your Matrix client did something funny with reply/thread tags, or this is a logic error on OOYE's side. At any rate, this should be reported for further investigation. You should also attach the error message that's about to be sent below (or on the main room timeline, if the command was ran inside a thread).",
|
||||
})
|
||||
throw e;
|
||||
}
|
||||
if (isFallingBack) throw e; //Discord claims that there already exists a thread for the message ran this command was ran on, but that doesn't make logical sense, as it doesn't seem like it was ran on any message. Either the Matrix client did something funny with reply/thread tags, or this is a logic error on our side. At any rate, this 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.
|
||||
const thread = mxUtils.getThreadRoomFromThreadEvent(branchedFromMxEvent)
|
||||
return api.sendEvent(event.room_id, "m.room.message", {
|
||||
...ctx,
|
||||
|
|
@ -325,12 +318,7 @@ const commands = [{
|
|||
body: "Specified thread name is too long - thread creation failed. Please yap a bit less in the title, the thread body is for that. ;)"
|
||||
})
|
||||
|
||||
await api.sendEvent(event.room_id, "m.room.message", {
|
||||
...ctx,
|
||||
msgtype: "m.text",
|
||||
body: "⚠️ Unknown error occurred during thread creation. See error message below (or on the main room timeline, if the command was ran inside a thread) for details."
|
||||
})
|
||||
throw e
|
||||
throw e //Some other error happened, one that OOYE didn't anticipate the possibility of? It should be reported to us 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