The FrameworkSynchronizer aims to keep Isis' internal ResolveState in sync with the actual persistence state of the pojos. (One day we'll get rid of all this, just not yet).
In the meantime, in the postLoad callback, it's possible that the adapter has already been marked as destroyed, eg:
- the object was deleted in an action (ie queued a DestroyCommand
- subscriber on the action performed a post-execute which ran a query
- running the query flushed the command, causing the pojo to be deleted and its adapter to be set to destroyed
- in the commit, DN's clean up of query results causes pending pojos in result set to be resolved, triggering the postLoad callback method for a pojo that was deleted
We should therefore guard for the situation that the adapter is already set to be Destroyed.