test(rabbitmq): add coverage for new network semantic conventions

[bhawnapannu2701]

The existing RabbitMQ tests cover legacy network attributes. The spec now defines new network keys (e.g., network.peer.address/port, server.address/port). This test publishes and consumes a message and asserts that recorded spans contain at least one of the new attributes, increasing coverage without touching production code.

• Test-only change, no production code touched
• Runs locally with: gradlew test -p instrumentation/rabbitmq-2.7/javaagent
• Formatted via spotlessApply

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: otelbot[bot] / name: otelbot (f9b6b87)
• ✅ login: bhawnapannu2701 / name: Bhawna Pannu (dd5def2, e1a9b73, 4b7337f)

[jaydeluca]

Is there any reason not to make changes in the existing test classes where it already has all the container setup code etc?

There are already some assertions for network attributes, if you think there is something missing, you could look to update things there instead of a new class?

[otelbot-java-instrumentation]

🔧 The result from spotlessApply was committed to the PR branch.

[bhawnapannu2701]

Thanks for the feedback! I moved the assertions into the existing RabbitMqTest (reusing container/setup) and removed the extra class. The updated verifyNetAttributes accepts either legacy (network.peer.) or the newer semconv (server./client.*) keys via AttributeKey, so it passes under both configurations without production changes.

[laurit]

We don't implement the latest version of the messaging semantic conventions and thus don't emit attributes like server.address.

[bhawnapannu2701]

All checks have passed and the branch is up to date with my latest changes.
Please let me know if you’d like me to rebase or make any further edits.

[laurit]

All checks have passed and the branch is up to date with my latest changes. Please let me know if you’d like me to rebase or make any further edits.

@bhawnapannu2701 I'm sorry but we won't be merging this PR since the instrumentation does not emit these attributes. When the instrumentation is update we'll be using a flag like otel.semconv-stability.opt-in=messaging In the instrumentation code we'll emit the attributes based on the flag

opentelemetry-java-instrumentation/instrumentation-api-incubator/src/main/java/io/opentelemetry/instrumentation/api/incubator/semconv/db/DbClientAttributesExtractor.java

Lines 48 to 55 in c5da90a

	if (SemconvStability.emitStableDatabaseSemconv()) {
	internalSet(attributes, DB_QUERY_TEXT, getter.getDbQueryText(request));
	internalSet(attributes, DB_OPERATION_NAME, getter.getDbOperationName(request));
	}
	if (SemconvStability.emitOldDatabaseSemconv()) {
	internalSet(attributes, DB_STATEMENT, getter.getDbQueryText(request));
	internalSet(attributes, DB_OPERATION, getter.getDbOperationName(request));
	}

and in the test we also choose which attribute to assert on based on a flag

opentelemetry-java-instrumentation/instrumentation/jdbc/javaagent/src/test/java/io/opentelemetry/javaagent/instrumentation/jdbc/test/JdbcInstrumentationTest.java

Line 379 in c5da90a

equalTo(maybeStable(DB_SYSTEM), maybeStableDbSystemName(system)),

If you wish to work on updating the messaging attributes try to follow the established conventions used for updating the database conventions. Since this is going to be large project and will also involve changes in the span structure my advice would be for you to start small. Don't attempt to do everything in one PR.

[github-actions]

This PR has been labeled as stale due to lack of activity and needing author feedback. It will be automatically closed if there is no further activity over the next 7 days.