From c36fed72577ddf9d7e927436b78b56bdd06be6c3 Mon Sep 17 00:00:00 2001
From: Johannes Tax <johannes.tax@grafana.com>
Date: Mon, 22 Jan 2024 14:46:53 +0100
Subject: [PATCH 1/3] Add settle spans from OTEP 220
---
docs/messaging/messaging-spans.md | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/docs/messaging/messaging-spans.md b/docs/messaging/messaging-spans.md
index 19db054994..cdfa0c7d9c 100644
--- a/docs/messaging/messaging-spans.md
+++ b/docs/messaging/messaging-spans.md
@@ -206,6 +206,7 @@ The following operations related to messages are defined for these semantic conv
| `create` | A message is created. "Create" spans always refer to a single message and are used to provide a unique creation context for messages in batch publishing scenarios. |
| `receive` | One or more messages are requested by a consumer. This operation refers to pull-based scenarios, where consumers explicitly call methods of messaging SDKs to receive messages. |
| `deliver` | One or more messages are passed to a consumer. This operation refers to push-based scenarios, where consumer register callbacks which get called by messaging SDKs. |
+| `settle` | One or more messages are settled. |
### Span kind
@@ -269,6 +270,12 @@ batch of messages, or for no message at all (if it is signalled that no
messages were received). For each message it accounts for, the "Deliver" or
"Receive" span SHOULD link to the message's creation context.
+"Settle" spans SHOULD be created for every manually or automatically triggered
+settlement operation. A single "Settle" span can account for a single message
+or for multiple messages (in case messages are passed for settling as batches).
+For each message it accounts for, the "Settle" span MAY link to the creation
+context of the message.
+
## Messaging attributes
Messaging attributes are organized into the following namespaces:
From c0d16730c559e1dbc4ef39132088c2314ec5dfb0 Mon Sep 17 00:00:00 2001
From: Johannes Tax <johannes.tax@grafana.com>
Date: Fri, 26 Jan 2024 11:23:36 +0100
Subject: [PATCH 2/3] Allow system specific spans names as long as they are
documented
---
docs/messaging/messaging-spans.md | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/docs/messaging/messaging-spans.md b/docs/messaging/messaging-spans.md
index cdfa0c7d9c..33e7d9ba29 100644
--- a/docs/messaging/messaging-spans.md
+++ b/docs/messaging/messaging-spans.md
@@ -184,18 +184,19 @@ If the destination name is dynamic, such as a [conversation ID](#conversations)
In these cases, an artificial destination name that best expresses the destination, or a generic, static fallback like `"(anonymous)"` for [anonymous destinations](#temporary-and-anonymous-destinations) SHOULD be used instead.
The values allowed for `<operation name>` are defined in the section [Operation names](#operation-names) below.
-If the format above is used, the operation name MUST match the `messaging.operation` attribute defined for message consumer spans below.
Examples:
* `shop.orders publish`
* `shop.orders receive`
-* `shop.orders process`
+* `shop.orders settle`
* `print_jobs publish`
-* `topic with spaces process`
-* `AuthenticationRequest-Conversations process`
+* `topic with spaces deliver`
+* `AuthenticationRequest-Conversations settle`
* `(anonymous) publish` (`(anonymous)` being a stable identifier for an unnamed destination)
+Messaging system specific adaptions to span naming MUST be documented in [semantic conventions for specific messaging technologies](#semantic-conventions-for-specific-messaging-technologies).
+
### Operation names
The following operations related to messages are defined for these semantic conventions:
From 23580f56deba8c84d05cdbbfe5d57761567b9e34 Mon Sep 17 00:00:00 2001
From: Johannes Tax <johannes.tax@grafana.com>
Date: Tue, 6 Feb 2024 11:15:42 +0100
Subject: [PATCH 3/3] Add new changelog
---
.chloggen/661.yaml | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 .chloggen/661.yaml
diff --git a/.chloggen/661.yaml b/.chloggen/661.yaml
new file mode 100644
index 0000000000..dde1142c34
--- /dev/null
+++ b/.chloggen/661.yaml
@@ -0,0 +1,22 @@
+# Use this changelog template to create an entry for release notes.
+#
+# If your change doesn't affect end users you should instead start
+# your pull request title with [chore] or use the "Skip Changelog" label.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the area of concern in the attributes-registry, (e.g. http, cloud, db)
+component: messaging
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Add messaging semantic conventions for settlement spans
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+# The values here must be integers.
+issues: [621]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: