kasobol-msft

Options for HttpPipelinePolicy

Overview

This documents presents options for how to introduce sync API to HttpPipelinePolicy.

Current state

Currently the HttpPipelinePolicy is defined as

kasobol-msft

Introduction

Project Reactor is working on a new major version with tentative plan to baseline on JDK17 (following Spring's and Netty's decisions) as well as evolve APIs in a breaking change manner (since new baseline asks for new major revision anyway). This document is attempting to assess impact on Azure SDK for Java as well as propose couple of ways SDK could be solving this (and upcoming) migration.

Reactor usage in Azure SDK for Java

Azure SDK for Java uses Reactor to

1. Implement internals of asynchronous clients. Reactor helps building complex reactive streams that would otherwise require equivalent in-house framework (which is [not a trivial effort](https://githu

kasobol-msft

namespace ConsoleApp2
{
    using Azure.Identity;
    using Azure.Storage.Blobs;
    using Azure.Storage.Blobs.Models;
    using Microsoft.ApplicationInsights.DependencyCollector;
    using Microsoft.ApplicationInsights.EventSourceListener;
    using Microsoft.ApplicationInsights.Extensibility;
    using System;
    using System.Threading.Tasks;

kasobol-msft

// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License.

using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApp1
{

kasobol-msft

Scenario

Customers using Queue SDK can opt-in to base64-encode/decode queue messages in order to handle payloads that are not valid UTF-8 strings. This is currently supported in .NET and Python SDK.

This is working well if messages in the queue are uniform. I.e. they are all base64 encoded. However, if non-base64-encoded message (due to a bug or migration) appears in the queue we lack mechanism to gracefully handle this situation, i.e. discard the message from the queue and log/persist it somewhere else for further processing/audit (e.g. transfer such message to poison-queue).

Current behavior (.NET, Python)

Let's assume that customer has a queue with 20 messages and one of them is "bad", i.e. 19 base64-encoded messages and 1 message which is plain text (i.e. not valid base64 string).