span.kind can be imported from ext/tags as well

Same thing as your other comments. Other plugins are not using this file. Not sure why though.

I personally prefer strings, especially for tests where I want the expectation to be as obvious as possible without having to search for the underlying value.

When patching MessageSender.send are spans created in the following scenarios?

• Synchronous message send (no await)
• ServiceBusSender.sendMessages with a list of messages instead of a single message
• ServiceBusSender.scheduleMessages

• Azure service bus does not support synchronous message sending
• A list did not work, because it was converted into a batch class and encoded

           // Case 2: Batch message
           batch = messages;
       }
       else {
           // Case 3: Array of messages
           batch = await this.createMessageBatch(options);
           for (const message of messages) {
               throwIfNotValidServiceBusMessage(message, errorInvalidMessageTypeSingleOrArray);
               if (!batch.tryAddMessage(message, options)) {

• Did not try it, but based on the code I doubt it will work.

Batching and scheduling is non-trivial. We should revisit this later. I'll make cards for us to track them.

Not a blocker, but for a standard promise instrumentation, it would have been possible to use tracingChannel.tracePromise() to replace this whole block.

I personally prefer strings, especially for tests where I want the expectation to be as obvious as possible without having to search for the underlying value.

It would be more efficient to prepare the meta object before startSpan depending on the trigger, and then pass that directly.

For example:

const meta = getMetaForTrigger(ctx)

const span = this.startSpan(this.operationName(), {
  childOf,
  service: this.serviceName(),
  type: 'serverless',
  meta
}, false)

function getMetaForTrigger({ functionName, methodName, invocationContext }) {
  const meta = {
    'aas.function.name': functionName,
    'aas.function.trigger': mapTriggerTag(methodName)
  }

  if (triggerMap[methodName] === 'ServiceBus') {
    ...
  }

  return meta
}

Unrelated to this PR, but passing ctx here instead of false would remove the need to explicitly assign currentStore and parentStore to the context at the end of the function.

Out of scope of this PR but in the future I think it might be worth it to split things as multiple plugins instead of having an ever-growing switch.

Why 50 seconds? This seems very specific.

I asked @duncanpharvey about this before. He said it takes a while to start up the azure function runtime and 50 seconds gave enough cushion for the tests to pass reliably.

Ok, I guess I was just curious why 50 seconds and not a minute at that point 😄

The 50 second timeout was arbitrary