Why do I see a FunctionIndexingException when creating a QueueTrigger WebJob Function?

Question

I created a function like this

public static Task HandleStorageQueueMessageAsync(
    [QueueTrigger("%QueueName%", Connection = "%ConnectionStringName%")] string body,
    TextWriter logger)
    {
        if (logger == null)
        {
            throw new ArgumentNullException(nameof(logger));
        }

        logger.WriteLine(body);
        return Task.CompletedTask;
    }

The queue name and the connection string name come from my configuration that has an INameResolver to get the values. The connection string itself I put from my secret store into the app config at app start. If the connection string is a normal storage connection string granting all permissions for the whole account, the method works like expected.

However, in my scenario I am getting an SAS from a partner team that only offers read access to a single queue. I created a storage connection string from that which looks similar like

QueueEndpoint=https://accountname.queue.core.windows.net;SharedAccessSignature=st=2017-09-24T07%3A29%3A00Z&se=2019-09-25T07%3A29%3A00Z&sp=r&sv=2018-03-28&sig=token

(I tried successfully to connect using this connection string in Microsoft Azure Storage Explorer)

The queue name used in the QueueTrigger attribute is also gathered from the SAS

However, now I am getting the following exceptions

$exception  {"Error indexing method 'Functions.HandleStorageQueueMessageAsync'"}    Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexingException
InnerException  {"No blob endpoint configured."}    System.Exception {System.InvalidOperationException}

If you look at the connection string, you can see the exception is right. I did not configure the blob endpoint. However I also don't have access to it and neither do I want to use it. I'm using the storage account only for this QueueTrigger.

I am using Microsoft.Azure.WebJobs v2.2.0. Other dependencies prevent me from upgrading to a v3.x

What is the recommended way for consuming messages from a storage queue when only a SAS URI with read access to a single queue is available? If I am already on the right path, what do I need to do in order to get rid of the exception?

score 3 · Accepted Answer · answered Sep 28 '18 at 08:37

As you have seen, v2 WebJobs SDK requires access to blob endpoint as well. I am afraid it's by design, using connection string without full access like SAS is an improvement tracked but not realized yet.

Here are the permissions required by v2 SDK. It needs to get Blob Service properties(Blob,Service,Read) and Queue Metadata and process messages(Queue,Container&Object,Read&Process).

Queue Trigger is to get messages and delete them after processing, so SAS requires Process permission. It means the SAS string you got is not authorized correctly even if SDK doesn't require blob access.

You could ask partner team to generate SAS Connection String on Azure portal with minimum permissions above. If they can't provide blob access, v3 SDK seems an option to try.

But there are some problems 1. Other dependencies prevent updating as you mentioned 2. v3 SDK is based on .NET Core which means code changes can't be avoided. 3. v3 SDK document and samples are still under construction right now.

score 0 · Answer 2 · answered Oct 06 '20 at 08:59

0

I was having a load of issues getting a SAS token to work for a QueueTrigger.

Not having blob included was my problem. Thanks Jerry!

Slightly newer screenshot (I need add also):

answered Oct 06 '20 at 08:59

Peter

971
11
12

Why do I see a FunctionIndexingException when creating a QueueTrigger WebJob Function?

2 Answers2

Linked