How It Works

Browser-Native Architecture

Bussin is served as a static single-page application. Once the static HTML and WebAssembly resources are loaded into your browser, the tool operates entirely locally in your browser's security sandbox.

• Direct Connections: Your browser opens TCP connections directly to Azure. No third-party API or backend proxy server ever sees your connection data.
• No Data Storage: Because there is no backend server, your Service Bus credentials, folder settings, and message payloads are processed purely in local memory.

AMQP over WebSockets

Standard browser security sandboxes block direct HTTP REST requests to Azure Service Bus data-plane endpoints because they lack CORS headers. Bussin bypasses this limitation by establishing direct AMQP 1.0 connections over WebSockets (`wss://.servicebus.windows.net:443/$servicebus/websocket`).

Because WebSockets are exempt from CORS restrictions, your browser can safely pipe raw messaging frames directly to the Azure broker over TLS.

Authentication & Required Permissions

Authentication is handled directly in your browser using Microsoft's official library (MSAL.js) via the standard OAuth 2.0 PKCE flow. To list namespaces and manage messages, Bussin requests two delegated scopes:

• https://management.azure.com/user_impersonation: To list your namespaces and subscriptions.
• https://servicebus.azure.net/user_impersonation: To open data-plane connections to interact with queues and topics.

This means Bussin operates under your active identity and respects your existing Azure roles. To work with messages, ensure your account has one of these built-in roles assigned:

• Azure Service Bus Data Owner: Full permissions to send, read, and delete messages.
• Azure Service Bus Data Receiver: Read-only access to peek or receive messages.
• Azure Service Bus Data Sender: Write-only access to publish messages.

Visual Architecture Flow

This flow diagram shows how authentication, resource discovery, and messaging connections are handled entirely inside your browser's local sandbox:

Smart Messaging Operations

Because Azure Service Bus is a message queue (optimized for sequential stream processing) and not a database, the broker does not natively support "random-access" locking, deletion, or resubmission of specific active or DLQ messages by sequence number. To work around this design restriction and provide clean single-message operations, Bussin runs advanced background logic:

The Lock-Match-Complete Pattern

To delete or resubmit a single message located deep in a queue without affecting other messages, Bussin executes a custom transaction-adjacent workflow:

1. Sequence Scanning: The tool scans message sequences in your browser's local memory to locate the target message's index and sequence ID.
2. Offset-Based Locking: It opens a standard receiver link and lock-retrieves messages from the head of the queue sequentially until the target message is successfully retrieved and locked (e.g. if the target is at index 4, it locks 4 messages).
3. Settle and Release: The target message is explicitly settled (Completed, Dead-Lettered, or Resubmitted), while the other messages locked during the scan are immediately abandoned (Released) to return back to their original position at the front of the queue.

Transaction & Duplication Safeguards

When you trigger a message resubmission (cloning and sending a failed DLQ message back to the active queue), Bussin guarantees message preservation through strict action ordering:

• Publish Before Delete: The new cloned message is successfully published to the target destination before the original is settled and removed from the source queue.
• Source Preservation: If the publish step fails, the operation halts immediately. The original message is never settled or removed, ensuring your data is preserved.
• At-Least-Once Delivery: In case the publish succeeds but the subsequent deletion of the original fails (due to connection loss or lock expiration), the message will exist in both the target and source queues. This safely conforms to standard distributed messaging principles, prioritizing duplication over data loss.