Queueable apex invoked from triggers doesn't inherit sharing correctly

Question

Consider the following class:

public inherited sharing class testQueueableSharing implements Queueable {
    public void execute(QueueableContext context) {
        update [SELECT Id FROM User WHERE Name='User User'];
    }
}

Which is invoked from a trigger, by a standard user:

trigger TestTriggerExecutePolicy on Lead (before insert, before update, before delete, after insert, after update, after delete) {
    System.enqueueJob(new testQueueableSharing());
}

Will throw an exception, while declaring class without sharing or calling update from trigger directly succeeds.

Does queueable apex not support inherited sharing? Isn't this something that at least the compiler should catch?

Answer 1

This is the proper behavior. Once you request a Future, Queueable, Schedulable, Batchable or cancelable Platform Event, it will be queued for a separate transaction. When that separate transaction runs, a security context will be established at that point in time. If the class is without sharing or not specified, it will run without sharing, but if it is with sharing or inherited sharing, it will be with sharing.

This is because the newly spawned transaction does not remember the previous transaction's security mode; this is not part of the state that is serialized for the transaction. If you need the mode to be preserved, you'll have to do it "manually" by using an execution class with the correct context set (see my answer on a sample implementation).

I would say that this is a bit confusing (compared to not-specified sharing), but it really is meant to, by default, establish that sharing is enabled unless called from a without sharing context. You should treat inherited sharing as with sharing for most practical purposes other than utility classes. This is the polar opposite of the not-specified sharing mode.