hook_ENTITY_TYPE_access is getting called in /bibcite/reference/add/{type}

hook_ENTITY_TYPE_access is getting called in /bibcite/reference{type}

You mean on reference entity view page like bibcite/reference/12345? It's expected behavior. Use $operation parameter and add a condition on it.

There is separate hook_ENTITY_TYPE_create_access() hook in Drupal for access handling on entity creation.

@antongp The I think the issue here is that hook_ENTITY_TYPE_access is called on the /bibcite/reference/add/{type} page and hook_ENTITY_TYPE_create_access should be called instead. Is that correct Lomas?

The bug here is that when one tries to add a Reference Entity via the form path /bibcite/reference/add/{type} :
First, \Drupal\Core\Entity\EntityAccessControlHandler::createAccess is checked and related create Access hooks are invoked which are like hook_ENTITY_TYPE_create_access() . This is the correct behavior.
But then the control also goes to any hooks which are like hook_ENTITY_TYPE_access which means $entity->access() is also invoked during form render and I found it is called to check delete operation #access . This is an unexpected behaviour and also is not consistent with Nodes.

Example to understand, why this is a problem - Let's say we have a custom access check wrapper around bibcite's access check and we use hook_ENTITY_TYPE_create_access for create related access wrappers and hook_ENTITY_TYPE_access for other operations such as update/delete/etc .
Assuming this works correctly, one can write code like $reference_entity->id() in his custom access checker which is invoked from hook_ENTITY_TYPE_access, as by this time entity is not new and id is available, but due to the bug - this will be called for first-time entity creation during form render, so this would definitely fail or break as id() will be called on null.

I am debugging this and will be creating a patch for a fix.

This fixes the issue, this is inspired as to how Node handle's this check. NodeForm let's Drupal\Core\Entity\EntityForm::actions handle the entity->isNew() check and then works on it if delete is present, I think we can follow the same here. Please review.