[Service Bus] SDK binding rejects messages without x-opt-lock-token annotation despite host-provided lock-token prefix

Open Beginner friendly
  • Is something wrong?
#180 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
azure, node.js, typescript
Domain
api, backend

Research direction

Read azure-functions-nodejs-extensions-servicebus/src/util/serviceBusMessageDecoder.ts, especially the decoder’s lock-token checks and prefix parsing. Compare its behavior with the reported binding content: a 16-byte GUID prefix followed by raw AMQP bytes. Add regression coverage for annotation-free messages and nonzero GUID byte ordering, then confirm conversion returns the token from the prefix.

Written by the indexing model from the issue text.

Description

Summary

@azure/functions-extensions-servicebus version 0.5.1 fails to convert incoming messages when their AMQP representation lacks x-opt-lock-token, even when binding content includes the 16-byte lock-token prefix supplied by the Functions host.

The affected topic receives REST-published messages. Every observed invocation fails before entering the handler. We have not captured the failing host payload, so the relationship to REST publishing remains an observation rather than a confirmed cause.

Environment

  • @azure/functions-extensions-servicebus: 0.5.1
  • @azure/functions: 4.17.0
  • Azure Functions on Windows
  • Host version shown in worker path: 4.1055.300
  • Extension bundle: Microsoft.Azure.Functions.ExtensionBundle, range [4.0.0, 5.0.0)
  • Trigger: sdkBinding: true, cardinality: 'one'
  • autoCompleteMessages: false in host configuration and trigger registration

Actual Behavior

Invocation fails during argument conversion, before the handler runs:

Unable to create client. Please register the extensions library with your function app.
Error: Lock token not found in content

at fromRpcTypedData.ts:40:19
at InvocationModel.ts:85:29
at InvocationModel.getArguments

Disabling autocompletion and using manual settlement did not resolve the error.

Reproduction

Construct binding content with a 16-byte GUID prefix followed by an AMQP message without x-opt-lock-token. The extension factory throws Lock token not found in content.

Adding message_annotations: { 'x-opt-lock-token': Buffer.alloc(16) } makes conversion succeed, with the returned token correctly read from the prefix.

We reproduced identical results using the native CommonJS SDK entry point and a minified esbuild bundle.

Expected Behavior and Suspected Cause

The host's ConvertReceivedMessageToBindingData serializes 16 GUID bytes followed by raw AMQP bytes.

However, ServiceBusMessageDecoder.decode first searches for x-opt-lock-token and throws if absent, although it subsequently reads the token from the prefix.

Could the decoder validate and read the prefix directly without requiring the annotation? Regression coverage should include annotation-free messages and nonzero GUID byte ordering.

Impact

All observed invocations of the affected function fail before business processing or settlement can run.

Dominant language
TypeScript
Stars
2
Forks
8
Avg merge
5d 10h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Azure/azure-functions-nodejs-extensions

All issues in Azure/azure-functions-nodejs-extensions

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.