Issue

After deploying changes to a Mendix Cloud environment, the OData metadata in the Catalog does not reflect the latest service definition. A consuming application continues to see outdated metadata, for example, an attribute treated as calculated instead of stored, which prevents filtering on that attribute. The Update Contract button is disabled, so the contract cannot be updated manually, and the data source is marked as automatically registered.

Environment

Mendix Cloud

Cause

For apps deployed through Mendix Cloud, the Catalog registers integration metadata automatically on every deployment. Changing such a data source manually is not possible by design, because the metadata is kept up to date with each deployment and manual changes would be overwritten on the next one. The disabled Update Contract button is expected behavior for these data sources.

The likely cause of stale metadata is reusing the same service version across environments:

• A version number (for example, 1.0.0) is the unique key for a version within a service. The Catalog stores the last definition received for that version.
• Service versions are part of the model and are not specific to an environment. The same version can be deployed to non-production and production.
• Changes to a given version are reflected for every environment where that version is published. If 1.0.0 exists in both non-production and production, a deployment or restart of one environment overwrites the shared 1.0.0 metadata for both.

As a result, deploying or restarting an environment with an older specification of the same version number overwrites the newer specification, and the consuming app keeps seeing the outdated metadata.

Solution / Workaround

Apply semantic versioning so each updated contract is registered as a distinct version, then upgrade the consuming app. Follow these steps:

1. Increment the API version. In the Mendix model, raise the OData service version (for example, from 1.0.0 to 1.1.0) to reflect the change, such as an attribute moving from calculated to stored.
2. Redeploy the updated model. The Catalog registers the new version alongside the existing one, so each environment publishes its own version and they no longer overwrite each other.
3. Upgrade the contract in the consuming app. Open the consumer app in Studio Pro, detect the new service version, and upgrade the consumed OData contract.
4. Retest filtering. Confirm the attribute is recognized as stored and that filtering works as expected.

Expected result: each environment registers a distinct version, and the consuming app uses the updated, refreshed metadata.

Additional information

Mendix documentation: Registering Resources in the Catalog