When panama team attempts to ingest, the object is only partially formed and has no parent. it appears to be a permissions/authorization problem, not a network problem like originally thought. I logged in using Panama team log in and experienced the same behavior as the panama team, which ruled out a lag issue.

The ownerId in DC of the new concept made in the test and the parent concept are both "cooker" meaning that it should be ok in the permissions.
I am going to look both in the Islandora permission and the global policies then at the code.

It looks like the XACML policies on si-fedora are not correctly set up.
The policy: deny-policy-management-if-not-administrator.xml was supposed to be removed.
The policy: deny-policy-management-if-not-administrator-or-owner.xml was supposed to be added.
The https://github.com/Smithsonian/sidora/blob/6.x/data/xacml/deny-policy-management-if-not-administrator-or-owner.xml because Nigel edited it on si-fedoradev, I think, to test some ideas about group access. I am going to do checksums on what is stored in GitHub, si-fedoradev and si-fedora on all the policies.
But the above would cause the problem we are seeing.

Besides the extra policies and the missing policies in production the policy deny-policy-management-if-not-administrator-or-owner.xml in si-fedoradev does not match the one in Github so its been edited. Now we need to check if they functionally match (spaces and comments affect the checksums).

Dan fixed up the policies and restarted Fedora on production. Unfortunately, its still broken. I had hoped the missing policy "permit-anything-to-owner.xml" was the problem. However, it is clear from the logs that we get an authorization failure from Fedora when there is an attempt to write a new RELS-EXT into the "parent" concept. The owner of the parent object is "cooker" and so is the owner of the new object being constructed.

I will have to trace this back into the code to see that both the loginId and the owner are available to execute the REST call to update the parent's RELS-EXT so the policy does not deny write access. I am not able to try si-fedoradev since there does not seem to be the same data available. At least the problem is clearly authorization for a non-admin user (an owner).

The is a difference in the "deny-policy-management-if-not-administrator-or-owner.xml" between Github and si-fedoradev but that policy should not fire in this case. I ran using both the policy for si-fedoradev and the one from Github but it had no effect.