How to tell Azure Function Queue Trigger not to retry message










0















I have several Azure Functions with Queue Triggers. In Version 2



public static void Run(string message, ICollector<string> output, ILogger log) 
try DoMyFunction(message, output, log);
catch // HOWTO: Tell Queue Not to Bother Retrying



All onwards Queues are as output collections.



Given a Message that is not supported
When then message is processed by my function
Then my function should return a status that ensures the message is not retried


I am assuming that an HTTP 400 Bad Request is what we're after - therefore I'm looking for the equivalent of



public static HttpStatusCode Run(string message, ICollector<string> output, ILogger log)

try
DoMyFunction(message, output, log);
return HttpStatusCode.OK;

catch return HttpStatusCode.BadRequest;










share|improve this question






















  • From your description I am not sure what your intent is. Maybe this is a solution for you stackoverflow.com/questions/44786141/…

    – Sebastian Achatz
    Nov 15 '18 at 14:26











  • No - This is a response to one specific message only. If the message is invalid - please don't try again. It may be that legal messages fail halfway through and need to be retried.

    – David Lapeš
    Nov 15 '18 at 17:23












  • @DavidLapeš, where would you be returning the HTTP status code in this case? what is your output supposed to be? Note that you can only return an HTTP response to an HTTP request

    – Marie Hoeger
    Nov 16 '18 at 0:46












  • This is to signal to the ServiceBus that the message is unsupported and should be deadlettered

    – David Lapeš
    Nov 16 '18 at 14:00















0















I have several Azure Functions with Queue Triggers. In Version 2



public static void Run(string message, ICollector<string> output, ILogger log) 
try DoMyFunction(message, output, log);
catch // HOWTO: Tell Queue Not to Bother Retrying



All onwards Queues are as output collections.



Given a Message that is not supported
When then message is processed by my function
Then my function should return a status that ensures the message is not retried


I am assuming that an HTTP 400 Bad Request is what we're after - therefore I'm looking for the equivalent of



public static HttpStatusCode Run(string message, ICollector<string> output, ILogger log)

try
DoMyFunction(message, output, log);
return HttpStatusCode.OK;

catch return HttpStatusCode.BadRequest;










share|improve this question






















  • From your description I am not sure what your intent is. Maybe this is a solution for you stackoverflow.com/questions/44786141/…

    – Sebastian Achatz
    Nov 15 '18 at 14:26











  • No - This is a response to one specific message only. If the message is invalid - please don't try again. It may be that legal messages fail halfway through and need to be retried.

    – David Lapeš
    Nov 15 '18 at 17:23












  • @DavidLapeš, where would you be returning the HTTP status code in this case? what is your output supposed to be? Note that you can only return an HTTP response to an HTTP request

    – Marie Hoeger
    Nov 16 '18 at 0:46












  • This is to signal to the ServiceBus that the message is unsupported and should be deadlettered

    – David Lapeš
    Nov 16 '18 at 14:00













0












0








0








I have several Azure Functions with Queue Triggers. In Version 2



public static void Run(string message, ICollector<string> output, ILogger log) 
try DoMyFunction(message, output, log);
catch // HOWTO: Tell Queue Not to Bother Retrying



All onwards Queues are as output collections.



Given a Message that is not supported
When then message is processed by my function
Then my function should return a status that ensures the message is not retried


I am assuming that an HTTP 400 Bad Request is what we're after - therefore I'm looking for the equivalent of



public static HttpStatusCode Run(string message, ICollector<string> output, ILogger log)

try
DoMyFunction(message, output, log);
return HttpStatusCode.OK;

catch return HttpStatusCode.BadRequest;










share|improve this question














I have several Azure Functions with Queue Triggers. In Version 2



public static void Run(string message, ICollector<string> output, ILogger log) 
try DoMyFunction(message, output, log);
catch // HOWTO: Tell Queue Not to Bother Retrying



All onwards Queues are as output collections.



Given a Message that is not supported
When then message is processed by my function
Then my function should return a status that ensures the message is not retried


I am assuming that an HTTP 400 Bad Request is what we're after - therefore I'm looking for the equivalent of



public static HttpStatusCode Run(string message, ICollector<string> output, ILogger log)

try
DoMyFunction(message, output, log);
return HttpStatusCode.OK;

catch return HttpStatusCode.BadRequest;







azure-functions azure-queues






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 15 '18 at 11:40









David LapešDavid Lapeš

656




656












  • From your description I am not sure what your intent is. Maybe this is a solution for you stackoverflow.com/questions/44786141/…

    – Sebastian Achatz
    Nov 15 '18 at 14:26











  • No - This is a response to one specific message only. If the message is invalid - please don't try again. It may be that legal messages fail halfway through and need to be retried.

    – David Lapeš
    Nov 15 '18 at 17:23












  • @DavidLapeš, where would you be returning the HTTP status code in this case? what is your output supposed to be? Note that you can only return an HTTP response to an HTTP request

    – Marie Hoeger
    Nov 16 '18 at 0:46












  • This is to signal to the ServiceBus that the message is unsupported and should be deadlettered

    – David Lapeš
    Nov 16 '18 at 14:00

















  • From your description I am not sure what your intent is. Maybe this is a solution for you stackoverflow.com/questions/44786141/…

    – Sebastian Achatz
    Nov 15 '18 at 14:26











  • No - This is a response to one specific message only. If the message is invalid - please don't try again. It may be that legal messages fail halfway through and need to be retried.

    – David Lapeš
    Nov 15 '18 at 17:23












  • @DavidLapeš, where would you be returning the HTTP status code in this case? what is your output supposed to be? Note that you can only return an HTTP response to an HTTP request

    – Marie Hoeger
    Nov 16 '18 at 0:46












  • This is to signal to the ServiceBus that the message is unsupported and should be deadlettered

    – David Lapeš
    Nov 16 '18 at 14:00
















From your description I am not sure what your intent is. Maybe this is a solution for you stackoverflow.com/questions/44786141/…

– Sebastian Achatz
Nov 15 '18 at 14:26





From your description I am not sure what your intent is. Maybe this is a solution for you stackoverflow.com/questions/44786141/…

– Sebastian Achatz
Nov 15 '18 at 14:26













No - This is a response to one specific message only. If the message is invalid - please don't try again. It may be that legal messages fail halfway through and need to be retried.

– David Lapeš
Nov 15 '18 at 17:23






No - This is a response to one specific message only. If the message is invalid - please don't try again. It may be that legal messages fail halfway through and need to be retried.

– David Lapeš
Nov 15 '18 at 17:23














@DavidLapeš, where would you be returning the HTTP status code in this case? what is your output supposed to be? Note that you can only return an HTTP response to an HTTP request

– Marie Hoeger
Nov 16 '18 at 0:46






@DavidLapeš, where would you be returning the HTTP status code in this case? what is your output supposed to be? Note that you can only return an HTTP response to an HTTP request

– Marie Hoeger
Nov 16 '18 at 0:46














This is to signal to the ServiceBus that the message is unsupported and should be deadlettered

– David Lapeš
Nov 16 '18 at 14:00





This is to signal to the ServiceBus that the message is unsupported and should be deadlettered

– David Lapeš
Nov 16 '18 at 14:00












2 Answers
2






active

oldest

votes


















1














The messageHandlerOptions in host.json for Service Bus will be useful to you (specifically, autoComplete). Instead of returning an HTTP response, which doesn't make sense in the context of Azure Functions bindings, you can use methods on BrokeredMessage. This stackoverflow post may be helpful, although note that the answer is out of date.



When looking for documentation no this, you should look for information about the Service Bus binding and not "Queue storage" or "Queue Trigger", as these bindings are for Azure Storage queues.






share|improve this answer























  • This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

    – David Lapeš
    Nov 20 '18 at 9:47


















0














If I understand correctly, you should configure you function in host.json and set maxDequeueCount to 1.






share|improve this answer























  • That would apply to all cases not this specific message.

    – David Lapeš
    Nov 15 '18 at 17:21






  • 1





    Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

    – Nick
    Nov 15 '18 at 17:52











  • Fair point - I'll mull that one over.

    – David Lapeš
    Nov 16 '18 at 13:59










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53318705%2fhow-to-tell-azure-function-queue-trigger-not-to-retry-message%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














The messageHandlerOptions in host.json for Service Bus will be useful to you (specifically, autoComplete). Instead of returning an HTTP response, which doesn't make sense in the context of Azure Functions bindings, you can use methods on BrokeredMessage. This stackoverflow post may be helpful, although note that the answer is out of date.



When looking for documentation no this, you should look for information about the Service Bus binding and not "Queue storage" or "Queue Trigger", as these bindings are for Azure Storage queues.






share|improve this answer























  • This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

    – David Lapeš
    Nov 20 '18 at 9:47















1














The messageHandlerOptions in host.json for Service Bus will be useful to you (specifically, autoComplete). Instead of returning an HTTP response, which doesn't make sense in the context of Azure Functions bindings, you can use methods on BrokeredMessage. This stackoverflow post may be helpful, although note that the answer is out of date.



When looking for documentation no this, you should look for information about the Service Bus binding and not "Queue storage" or "Queue Trigger", as these bindings are for Azure Storage queues.






share|improve this answer























  • This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

    – David Lapeš
    Nov 20 '18 at 9:47













1












1








1







The messageHandlerOptions in host.json for Service Bus will be useful to you (specifically, autoComplete). Instead of returning an HTTP response, which doesn't make sense in the context of Azure Functions bindings, you can use methods on BrokeredMessage. This stackoverflow post may be helpful, although note that the answer is out of date.



When looking for documentation no this, you should look for information about the Service Bus binding and not "Queue storage" or "Queue Trigger", as these bindings are for Azure Storage queues.






share|improve this answer













The messageHandlerOptions in host.json for Service Bus will be useful to you (specifically, autoComplete). Instead of returning an HTTP response, which doesn't make sense in the context of Azure Functions bindings, you can use methods on BrokeredMessage. This stackoverflow post may be helpful, although note that the answer is out of date.



When looking for documentation no this, you should look for information about the Service Bus binding and not "Queue storage" or "Queue Trigger", as these bindings are for Azure Storage queues.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 17 '18 at 0:56









Marie HoegerMarie Hoeger

58117




58117












  • This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

    – David Lapeš
    Nov 20 '18 at 9:47

















  • This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

    – David Lapeš
    Nov 20 '18 at 9:47
















This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

– David Lapeš
Nov 20 '18 at 9:47





This is useful - but I will need to change the implementation in all my other functions to take control of completion. It would be useful to have this as an attribute on the entry point or binding.

– David Lapeš
Nov 20 '18 at 9:47













0














If I understand correctly, you should configure you function in host.json and set maxDequeueCount to 1.






share|improve this answer























  • That would apply to all cases not this specific message.

    – David Lapeš
    Nov 15 '18 at 17:21






  • 1





    Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

    – Nick
    Nov 15 '18 at 17:52











  • Fair point - I'll mull that one over.

    – David Lapeš
    Nov 16 '18 at 13:59















0














If I understand correctly, you should configure you function in host.json and set maxDequeueCount to 1.






share|improve this answer























  • That would apply to all cases not this specific message.

    – David Lapeš
    Nov 15 '18 at 17:21






  • 1





    Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

    – Nick
    Nov 15 '18 at 17:52











  • Fair point - I'll mull that one over.

    – David Lapeš
    Nov 16 '18 at 13:59













0












0








0







If I understand correctly, you should configure you function in host.json and set maxDequeueCount to 1.






share|improve this answer













If I understand correctly, you should configure you function in host.json and set maxDequeueCount to 1.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 15 '18 at 16:19









NickNick

2,0301213




2,0301213












  • That would apply to all cases not this specific message.

    – David Lapeš
    Nov 15 '18 at 17:21






  • 1





    Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

    – Nick
    Nov 15 '18 at 17:52











  • Fair point - I'll mull that one over.

    – David Lapeš
    Nov 16 '18 at 13:59

















  • That would apply to all cases not this specific message.

    – David Lapeš
    Nov 15 '18 at 17:21






  • 1





    Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

    – Nick
    Nov 15 '18 at 17:52











  • Fair point - I'll mull that one over.

    – David Lapeš
    Nov 16 '18 at 13:59
















That would apply to all cases not this specific message.

– David Lapeš
Nov 15 '18 at 17:21





That would apply to all cases not this specific message.

– David Lapeš
Nov 15 '18 at 17:21




1




1





Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

– Nick
Nov 15 '18 at 17:52





Then simply don't fail the function in this particular case. Just ignore the message you don't want to process, and return success.

– Nick
Nov 15 '18 at 17:52













Fair point - I'll mull that one over.

– David Lapeš
Nov 16 '18 at 13:59





Fair point - I'll mull that one over.

– David Lapeš
Nov 16 '18 at 13:59

















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53318705%2fhow-to-tell-azure-function-queue-trigger-not-to-retry-message%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Top Tejano songwriter Luis Silva dead of heart attack at 64

ReactJS Fetched API data displays live - need Data displayed static

政党