No negotiation with id ... found

[Arthur380]

Hello,

I'm encountering an issue with contract negotiations in a Kubernetes environment that doesn't happen locally.
When my provider connector attempts to send the agreement, I get the following error:

DSP: Service call failed: No negotiation with id 43e47248-6324-4320-8c1b-ceabfa12d089 found
ContractNegotiation: ID 763c0a59-88d3-4646-855a-e37d03b826f8. [Provider] send agreement
ContractNegotiation: ID 763c0a59-88d3-4646-855a-e37d03b826f8. Fatal error while [Provider] send agreement. Error details: {"@type":"dspace:ContractNegotiationError","dspace:code":"404","dspace:reason":"No negotiation with id 43e47248-6324-4320-8c1b-ceabfa12d089 found","@context":{"dcat":"http://www.w3.org/ns/dcat#","dct":"http://purl.org/dc/terms/","odrl":"http://www.w3.org/ns/odrl/2/","dspace":"https://w3id.org/dspace/v0.8/","@vocab":"https://w3id.org/edc/v0.0.1/ns/","edc":"https://w3id.org/edc/v0.0.1/ns/"}}
ContractNegotiation 763c0a59-88d3-4646-855a-e37d03b826f8 is now in state TERMINATED

On the provider side, the negotiation remains in the AGREEING state, while on the consumer side, it stays in the REQUESTED state. It seems the provider is no longer able to reach the consumer to verify the negotiation ID, even though the consumer pod is running and reachable.

I’ve tested the network connectivity between the pods (provider → consumer) using curl on the counterPartyAddress, and the connection works fine.

Both connectors are exposed through an ingress controller, which routes requests based on the hostnames defined in the following properties: web.http.public, web.http.management, web.http.protocol

The consumer accesses the provider using the ingress hostname defined in the counterPartyAddress property.

Have you encountered this issue before? Do you have any idea what could be causing it?
Let me know if there’s any additional info I can provide to help troubleshoot this.

Thanks in advance!

[Arthur380]

I just found my mistake: my Kubernetes ConfigMaps were misconfigured, which caused both connectors to use the same ConfigMap, resulting in conflicts.