Guzio/out-of-your-element
1
0
Fork 0
forked from cadence/out-of-your-element
Code Pull requests Activity

Why did I make it this way??? #13

Merged
Guzio merged 121 commits from main into mergable-fr-fr 2026-04-15 20:05:01 +00:00
Conversation 0 Commits 121 Files changed 79 +3131 -1041
Guzio commented 2026-04-15 20:04:20 +00:00
Owner
Copy link

this branch has 0 reason to exist but I'm stuck with it because I can't change which branch does my PR pull from:<

this branch has 0 reason to exist but I'm stuck with it because I can't change which branch does my PR pull from:<
Guzio added 121 commits 2026-04-15 20:04:20 +00:00 
At least final-until-we-make-it-so-that-new-rooms-are-autogenerated-when-a-thread-is-opened. Then we'd need to include the link to it instead of a command-help.
It's 23:42; I'm going just purely based on vibes at this point.

vibecoding but no AI, just eepy
Also, that message in thread-to-announcement was misleading, as now there's no guarantee that a thread was newly created (it could be very old, but freshly /thread-ed). So I changed that, too.

Also, while updating messages, I decided to slightly alter the „may not have been bridged to Discord in the way you thought it was gonna be”-warning in event-dispatcher.
In other news: Made /thread work without args (in SOME cases).

I'm pretty sure this is the final patch before we go PR.
So the code-key DOES exist. HuuuHhhhhh???
and yea, ofc it was a string......
As a part of that:
* rewrote the tests to support my changed behaviors
* added a missing case
* Made my „threads get attached to” wording more consistent with the test cases („threads branch from”), as I always felt that there was something off about my phrasing, but I couldn't quite tell what was it. OOYE's „branch” term seems much more fitting there
* slightly cooked the testing data (changed the „Hey.” thread from „floating” to being a branch of a message, to accommodate...)
* 3 NEW TESTS: of the function created in my previous commit (I'm not sure if this *REALLY* needed testing, given how braindead-simple that function is, but everything else in utils.js is covered, so I figured it's only fair to test this, too)

EXTRA CHANGE: fixed that function's name (we're getting the thread from a (Matrix) Event, not a (Discord) Message) and description (I totally didn't copy-paste the JSDoc from above........)
I passed a completely wrong event ID and was confused as to why could it possibly be failing. (Btw, as part od fixing that - my new function from function is utils.js now supports blank values.)

Also - and that's unrelated to the bug I was debugging - I put a guard clause in my if (words.length < 2) backwards. If->return should canonically be above the logic, even if it technically doesn't break said logic in this case (all it was doing was creating an extra step that says „yea, name the newly-created thread /thread, even if this name is very stupid, and also pointless because no thread creation is about to take place”. And while fixing that, I also did some minor changes to error handling.
just a little bit

I like it.

But it's just a little bit annoying.
Reviewed-on: #8
So that I can squash-merge it all without leaving the trace of any extra unsolicited changes
Turns out that auto-create is ALWAYS on for threads (which creates some hilarious situations, where the channel gets duplicated if it ever got unbridged). Also, manual bridging isn't even possible. Uhh... Sure! Let's just say, then, that it's the admin's problem to auto-create it (given the duplication - this is probably a better idea to leave it to them).

A proper fix for this (and also to limit (tho not fix) the dupe-by-autocreate problem) would probably be to allow for manual bridging on threads, but I really don't have time for this before The Merge (my ADHD is kicking-in on this update, and I have a feeling that if I don't PR soon, I'm gonna not do it for another 3 months).
Reviewed-on: #9
of course I did
This PR addresses a bridge crash discovered while backfilling old channels, alongside a wee QoL fix for the test suite.

* **Expired Events (`d2m`):** Wraps Discord scheduled event/invite link lookups in a try-catch block. If a link is expired (404 or Discord error 10006), the bridge now posts a fallback `m.notice` rather than throwing an error and halting message conversion.
* **Test Suite Setup:** Updates `test.js` to initialize the mock registration object using `getTemplateRegistration()` preventing test runner crashes when running without a local `registration.yaml` file.

Co-authored-by: Cadence Ember <cadence@disroot.org>
Reviewed-on: cadence/out-of-your-element#73
Co-authored-by: Bea <beanie@theargo.space>
Co-committed-by: Bea <beanie@theargo.space>
This updates the backfill script to attempt to create rooms for unbridged rooms, rather than bombing out that the room isn't already bridged.

Co-authored-by: Cadence Ember <cadence@disroot.org>
Reviewed-on: cadence/out-of-your-element#75
Co-authored-by: Bea <beanie@theargo.space>
Co-committed-by: Bea <beanie@theargo.space>
I was not supposed to do more pulling, but I started seeing some instability and I want to see if it's me or main.
- Refuse to link to encrypted rooms
- Do not show encrypted rooms as link candidates (if server supports)
- Reject invites to encrypted rooms with message
- Unbridge and leave room if it becomes encrypted
The sim_member cache was getting stuck, so OOYE thought it was already
in the room when it actually wasn't.
Override webhook username and avatar_url from m.per_message_profile
(and unstable com.beeper.per_message_profile) when present.
The stable key takes priority over the unstable prefix.
Remove data-mx-profile-fallback elements from formatted_body and
displayname prefix from plain body when per-message profile is used.
- Empty string "" -> undefined (Discord uses default avatar)
- Valid MXC URI -> convert to public URL
- Omitted/null -> keep member avatar
Apparently this was causing detached logs, so just stop those
complaints if the error isn't being bubbled
Both sides of creation (M2D and D2M) use ensureRoom() instead of syncRoom() because it's impossible to know which one will fire first, and we wouldn't want a double-sync. At the same time, calling ensureRoom() as a way to CREATE a thread-room is perfectly safe because „Naturally, the newly created room is already up to date, so we can always skip syncing here.” and also thread-rooms aren't subject to manual-mode restrictions, so we can skip all „Does a channel_room entry exists or guild autocreate = 1?” checks (actually, the comment probably should reflect that - so I updated the comments, too.

Also, bridgeThread() is a separate function to make guard clauses possible instead of nesting 3 more layers of IFs like we were fkin YandereDev.
Notably:
* Don't do the unmarshalling and switch-cases, as Cadence asked
* Revert command handler returns to how they were before, now that we're not using the returned-command-name anymore.
* use "" instead of „” to comply with English Language Standards Recommendations On Quotation Marks [TM], as per Cadence's request
* reflect current bot behavior (ie. it no longer bridges-as-replies, but mercilessly rips the message away from your caring arms)
* add Ellie-Mode
I was stripping the ping before because I thought it just pings the thread-author (which I found kinda pointless). But I didn't actually remove the code that figures out who to ping (because I happened to reuse the „if” around it, and didn't remove the setting itself because I didn't pay enough attention to it and just assumed it has some side-effects). I just tried to remove it finally (because my thought was „Wait, WHY are we setting m.mentions only to remove it?”), only to realize that the code does something entirely different (it pings the one under whose message a thread is about to be created, which makes a lot of sense tbh), and actually shouldn't be removed at all and - on the contrary - I should stop removing m.mentions (and also fix Ellie-Mode so that it won't prevent m.mentions from being set even if it's enabled).
I also noticed that my previous wiping code wasn't even doing anything at all. lmfao
Guzio merged commit f62468511b into mergable-fr-fr 2026-04-15 20:05:01 +00:00
Guzio referenced this pull request from a commit 2026-04-15 20:05:02 +00:00
unfuck my mess
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Guzio/out-of-your-element#13
No description provided.
Delete branch "main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?