Without seeing your code, it's a bit difficult to fully diagnose your issues. I can share some of my experience with apex managed sharing in community plus orgs and suggestions on architecture that you may find helpful.
First, let me say that while your transaction may have been initiated from the community side, Apex triggers and other code runs from within your org and is agnostic with respect to where the transaction was initiated from. Where it isn't though is with respect to any sharing permissions the user who initiated the transaction might have when
with sharing is taken into consideration. There's a huge difference between the permissions you have running the code from the Dev Console and when running it as a Community User.
What I have typically done when writing managed sharing code is:
- Use a trigger to write the transaction into a custom object
- A trigger on the custom object then calls a queueable
The queueable queries the custom object for unshared records
Note: Use the same custom object/queuable for ALL sharing. The queueable can act as a dispatcher to call other queuables specific to the type of record.
The sharing calculations are performed
- Any shares that might need removed are also calculated
- If successful, the record is deleted from the custom object
- If errors, a code/message is written to the record
- If previous error exists, email is sent to admin notifying record needs manual intervention
- Class is scheduled to run again for 2nd attempt to calculate sharing
Note: Instead of using a trigger on the custom object, a batch job can be scheduled at regular intervals to process all the records similar to what I've described. It all depends on how responsive you need the record sharing mechanism to be. In most cases, 24 hours is sufficient, but in others, it may need to be done hourly.
There are many benefits to doing this asynchronously. Typically, all the shares on the object will need to be recalculated. This can be very time consuming and process intensive. You don't want to "trigger" a complete recalculation of the sharing table for every single record if this occurs multiple times/day. Doing so can create problems with record locks and record contention.
Moving this into a batch or queuable job, moves the calculations away from the context of the original sharing permissions of the user who initiated the action. This is now completely out of the original execution context that started the process. In my experience, only large communities use a community plus license which means you're likely to have many records you'll be sharing. That also means you'll have a very large sharing table which you won't want to have recalculated multiple times/day which takes time and resources.
This pattern is also very scalable.