Skip to content

Conversation

ankitsmt211
Copy link
Member

During auto-archive routine for help threads, bot sends an embed educating OP why the thread was archived, it also pings OP in the process. This whole archiving routine depends on whether member was retrieved, thus it fails consecutively until discords built in archive feature kicks in.

image

@ankitsmt211 ankitsmt211 added bug Something isn't working priority: normal labels Dec 11, 2023
@ankitsmt211 ankitsmt211 self-assigned this Dec 11, 2023
@ankitsmt211 ankitsmt211 marked this pull request as ready for review December 11, 2023 19:18
@ankitsmt211 ankitsmt211 requested review from a team as code owners December 11, 2023 19:18
Zabuzard
Zabuzard previously approved these changes Dec 12, 2023
Zabuzard
Zabuzard previously approved these changes Dec 12, 2023
Copy link
Member

@Zabuzard Zabuzard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that duplication here isnt good:
dup

also, ur technically also attempting to archive when archiving itself failed, which isnt good.
the "try this, but always archive" shouldnt span across archiving itself.

instead, try to write it like:

...
.flatMap(member -> ...)
.onError(handleFailure)
.flatMap(any -> threadChannel.getManager().setArchived(true))
.queue();

@ankitsmt211
Copy link
Member Author

@Zabuzard im blank here, it requires me to return a RestAction<Message>, i don't think i can do that with OnError.... since we already handled with or without mention in mapToResult, there's no point in sending a new message. The only reason i was think to handle archiving as backup was if something breaks and AutoArchiver retries again and again so archive anyway. On a second note, do we even need it? Threads cant be deleted, only other variable was member leaving. Now if somehow it breaks then during second try, should be archived anyway. Thoughts?

image

@Zabuzard
Copy link
Member

might misremember the name. onFailure(...) perhaps.
personally, i dont mind u removing the error handling on that part. i dont think it's necessary

@ankitsmt211
Copy link
Member Author

seems much better, at least chain is pretty readable now.

Zabuzard
Zabuzard previously approved these changes Dec 14, 2023
@ankitsmt211
Copy link
Member Author

ankitsmt211 commented Dec 14, 2023

Don't merge yet.

@ankitsmt211
Copy link
Member Author

@Taz03 It's good to go when you can.

Taz03
Taz03 previously approved these changes Dec 15, 2023
* replacing Function type with Supplier for sendEmbedWithoutMention
* changing variable for more clarity on fetched members
Taz03
Taz03 previously approved these changes Dec 16, 2023
Copy link
Contributor

@marko-radosavljevic marko-radosavljevic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. ❤️

@marko-radosavljevic marko-radosavljevic merged commit 265d6a2 into Together-Java:develop Dec 27, 2023
@ankitsmt211 ankitsmt211 deleted the bug/member-left-guild branch December 27, 2023 18:13
@ankitsmt211 ankitsmt211 mentioned this pull request Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority: normal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants