writelock_issue #45
No reviewers
Labels
No labels
Automated
Backlog
Post_Prototype_1.0
Bot_Code
Core
Bot_Code
Custom
CI/CD
Complexity
Advanced
Complexity
Basic
Complexity
Expert
Complexity
Intermediate
Kind/Breaking
Kind/Bug
Kind/Bug Fix
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Nix
Ownership
Collab
Ownership
Collab with Leads
Ownership
Individual Lead
Ownership
In-Review
Ownership
Needs Owner > May Delegate
Ownership
Workshop with Leads
Phase 1.0
Requirements > Drafting
Phase 1.0
Requirements > Researching
Phase 1.0
Requirements > Review & Planning
Phase 2.0
Design > Research & Analysis
Phase 3.0
Coding > Implementation
Phase 4.0
QA > Unit Testing & Design
Phase 5.0
Resolution > Completed
Phase 5.0
Resolution > Review for Completion
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: modulatingforce/forcebot_rs#45
Loading…
Reference in a new issue
No description provided.
Delete branch "issue-chat-say-id-write-lock"
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?
After attempting to introduce functionality from #43 , noticing a complex issue with
write()
locks locking the bot at runtimeThis branch and PR intends to find recommendations for
write()
locks so we avoid the current lock observed with the aboveRelatively high priority - the parent PR has a lot of major changes, and this new PR is a show stopper
I'm not sure why there's an issue. This is working without issues, and isn't stuck in a lock
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=760930700e12552e2fb31f363c75d41f
As a Potential Workaround, I may want to keep the following in mind
Keep
IdentityManager.Can_User_Run()
towards operations that initially callBotActions
; these starting areas of validation can can use write locks so to auto mod usersWhile not robust , for read only access (that does not change from the input command), use
IdentityManager.getspecialroles()
At the moment, the following seems to not get stuck in a write lock in
say_in_reply_to
Read only seems to work for now - will be merging
WIP: writelock_issueto writelock_issue