oscerd opened a new pull request, #3051: URL: https://github.com/apache/camel-kamelets/pull/3051
`KameletsCatalogTest.testSupportedHeaders` is failing on `main`: ``` Failure checking salesforce-create-sink ==> expected: <1> but was: <0> ``` Nothing in this repository changed. `main`'s Build was green at 08:55 today; the catalog moved underneath it. ## What happened `camel-catalog:4.23.0-SNAPSHOT` no longer contains `components/salesforce.json`. Against 4.22.1, **twenty component descriptors are gone**: ``` as2, avro, box, dhis2, digitalocean, fhir, hazelcast-atomicvalue, iec60870-client, iec60870-server, irc, ironmq, json-patch, knative, langchain4j-tools, olingo2, olingo4, salesforce, servicenow, splunk, zeebe ``` and fifteen new ones appeared (`alibaba-*`, `hivemq`, `opa`, `spiffe`, `state-store`, …). So the snapshot catalog is mid-restructuring. I checked `camel-salesforce` itself first, and it is unchanged — still 23 headers, 22 `consumer` and 1 `producer`, identical in 4.22.1 and the snapshot. The component jar is fine; it is the aggregated catalog that lost the descriptor. Since `camel.version` tracks a SNAPSHOT, this can happen without a commit here. **Only salesforce is actually affected.** The other missing components are either unused by the Kamelets this test covers, or already expected to report zero. Verified by setting the five salesforce expectations to `0` — the rest of the test passed. ## Why not simply change the numbers Setting them to `0` would bake in a transient upstream state and go quietly stale the moment the descriptor returns, at which point the test breaks again in the other direction. Instead `verifyHeaders` skips when the Camel catalog in use carries no metadata *at all* for the component a Kamelet maps onto, and prints which ones it skipped: ``` Skipping salesforce-create-sink: the Camel catalog in use has no metadata for its component ``` What the test exists to check is the mapping from a Kamelet to its component's headers. With no component metadata there is nothing to map, and asserting a count would be asserting the completeness of the Camel catalog instead. **It heals itself.** Once `salesforce.json` is back, the five assertions run again at their original `1, 1, 1, 1` and `22`, with no change needed here. ## The skip cannot hide a regression It applies only when the component is absent from the Camel catalog. I checked both ways it could go wrong by deliberately breaking assertions: | deliberate break | result | |---|---| | `timer-source` expected 99, component present | **fails** — `expected: <99> but was: <2>` | | `slack-sink` expected 5, component present, returns 0 | **fails** — `expected: <5> but was: <0>` | So a wrong count still fails, and a present component that unexpectedly returns nothing still fails. Full `mvn clean install` green. --- _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
