bug: Azure Service Bus session receivers fail in the Go SDK, attach response has a bare session filter value

[ivan-penchev]

Current Behavior

Go clients can't accept a Service Bus session on LocalStack for Azure. Both
AcceptSessionForQueue and AcceptNextSessionForQueue fail with this error:

invalid described type header a1

The client sends the com.microsoft:session-filter entry in the source
filter set of its attach frame. LocalStack echoes that filter back in its
attach response, but drops the described-type wrapper. The value comes back
as a plain str8-utf8, which is byte 0xa1, or as vbin for
AcceptNextSession. The AMQP 1.0 spec, section 3.5.8, says filter-set
values must be described types or null. go-amqp follows the spec strictly,
so it rejects the frame and the receiver never opens.

The Python SDK azure-servicebus accepts sessions against the same
container. I think it just doesn't decode that field strictly. Every Go
service that uses sessions is blocked.

To confirm the cause, I patched a local copy of go-amqp so
Filter.Unmarshal accepts a value without the wrapper. About 10 lines.
With that patch everything works: named session, next session, complete,
abandon, and dead-lettering with MaxDeliveryCountExceeded. So the rest of
the broker looks fine. Only the echoed filter is wrong.

Expected Behavior

The attach response should echo the session filter as a described type, the
same way Azure Service Bus does. Descriptor is
com.microsoft:session-filter, code 0x00000137000000C, and the value is
the session ID string or null. Then the unpatched Go SDK accepts sessions.

How are you starting LocalStack?

With a docker run command

Steps To Reproduce

1. Start LocalStack for Azure:

   docker run --rm -p 4566:4566 -p 4510-4559:4510-4559 \
     -v /var/run/docker.sock:/var/run/docker.sock \
     -e LOCALSTACK_AUTH_TOKEN=$LOCALSTACK_AUTH_TOKEN \
     localstack/localstack-azure:latest

2. Through ARM, create a Service Bus namespace and a queue with
   requiresSession: true. Get the connection string from listKeys.

3. Run this with azservicebus v1.11.0, which pulls in go-amqp v1.7.0:

   package main
   
   import (
       "context"
       "fmt"
       "os"
   
       "github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus"
   )
   
   func main() {
       ctx := context.Background()
       c, err := azservicebus.NewClientFromConnectionString(os.Getenv("SB_CONN"), nil)
       if err != nil {
           panic(err)
       }
       s, _ := c.NewSender("kv-events", nil)
       sid := "s1"
       if err := s.SendMessage(ctx, &azservicebus.Message{Body: []byte("hi"), SessionID: &sid}, nil); err != nil {
           panic(err)
       }
       _, err = c.AcceptSessionForQueue(ctx, "kv-events", "s1", nil)
       fmt.Println(err) // invalid described type header a1
   }

Sending works. Accepting the session fails.

Environment

- OS: macOS on Apple Silicon, Docker through Colima (vz, arm64)
- LocalStack: localstack/localstack-azure:latest, version 2026.11.0.dev325. The `dev` tag fails the same way
- Go 1.27, azservicebus v1.11.0, go-amqp v1.7.0. Also fails with azservicebus v1.8.0 and go-amqp v1.3.0

Anything else?

Second, smaller session bug. If a session is already locked, a second
AcceptSessionForQueue on it succeeds. The error
com.microsoft:session-cannot-be-locked only comes on the first receive.
Azure refuses the attach itself, so clients expect the error from
AcceptSession. Exclusivity does hold, it's just reported late. Happy to
file this one separately if you prefer.

This is the go-amqp workaround I used, in internal/encoding,
Filter.Unmarshal:

var value DescribedType
if b, perr := r.PeekByte(); perr == nil && b != 0x0 {
    var raw any
    if err = Unmarshal(r, &raw); err != nil {
        return err
    }
    if b, ok := raw.([]byte); ok {
        raw = string(b)
    }
    value.Value = raw
} else if err = Unmarshal(r, &value); err != nil {
    return err
}