Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Storage queue trigger overwrites message ID with id in message body #882

Open
uberger opened this issue Nov 23, 2023 · 8 comments
Open
Assignees

Comments

@uberger
Copy link

uberger commented Nov 23, 2023

Investigative information

Please provide the following:
  • Python version: 3.10.5
  • Core Tools version: 4.0.5198
  • Function Runtime version: 4.21.1.20667

Repro steps

Provide the steps required to reproduce the problem:
  1. Create new functions app and install requirements.
  2. Create new function func new --name QueueTriggerFunc.
  3. Set the queue trigger connection in function.json to AzureWebJobsStorage.
  4. Edit the function code file __init__.py to be
    import logging
    import azure.functions as func
    
    def main(msg: func.QueueMessage) -> None:
        logging.info(f'msg.id: {msg.id}')
        logging.info('msg.body: %s',
                     msg.get_body().decode('utf-8'))
  5. Start Azurite, create queue named python-queue-items.
  6. Start Azure function host using func start.
  7. Using Azure Storage Explorer, add a new message to the python-queue-items with message body:
    {"id":"00000000-aaaa-0001-0003-00000000aaa1"}

Expected behavior

Provide a description of the expected behavior.

In the console output, the MessageId reported by the 'Trigger Details' should match the one one reported by the line starting with msg.id.

Actual behavior

Provide a description of the actual behavior observed.
  • The MessageId reported by the 'Trigger Details' is the correct, generated value, e.g. cf333465-97d3-4507-b50c-7b69308640d9.
  • The msg.id in the function code is overwritten with the value from the message body: 00000000-aaaa-0001-0003-00000000aaa1
[2023-11-23T10:36:48.769Z] Executing 'Functions.QueueTriggerFunc' (Reason='New queue message detected on 'python-queue-items'.', Id=faf613bc-24fb-4f69-b7bc-b75c3077beef)
[2023-11-23T10:36:48.775Z] Trigger Details: MessageId: cf333465-97d3-4507-b50c-7b69308640d9, DequeueCount: 1, InsertedOn: 2023-11-23T10:36:47.000+00:00
[2023-11-23T10:36:48.871Z] msg.body: {"id":"00000000-aaaa-0001-0003-00000000aaa1"}
[2023-11-23T10:36:48.871Z] msg.id: 00000000-aaaa-0001-0003-00000000aaa1
[2023-11-23T10:36:48.904Z] Executed 'Functions.QueueTriggerFunc' (Succeeded, Id=faf613bc-24fb-4f69-b7bc-b75c3077beef, Duration=155ms)

Contents of the requirements.txt file:

Provide the requirements.txt file to help us find out module related issues.
azure-functions
@bhagyshricompany bhagyshricompany self-assigned this Nov 27, 2023
@bhagyshricompany
Copy link

Thanks for reporting will check and update.

@bhagyshricompany
Copy link

Hi @uberger, it's an ID that is different from the message ID because when we insert a new item, it gets generated as a new autoincrement unique ID for ref you cen see in image.
image
image.

@uberger
Copy link
Author

uberger commented Nov 29, 2023

Thanks @bhagyshricompany for looking into this. Yes, I see the same behavior and understand that the Id in your screenshot is auto-generated by the Azure Storage Queue service. I expect that this Id is also accessible through the msg object that gets passed into the main method (msg.id). However, it is overwritten by the id I defined in the message body/message text. In your example I expect in the third to last log message to see

[timestamp] msg.id: bbcfe0e4-e177-4b25-9f8e-1223e4b8d1d3

Though, it prints the id from the message body/message text.

Maybe worth mentioning: If I send a message that does not contain an id property in the JSON string it works as expected.

@bhagyshricompany
Copy link

yes you can
image
image

@uberger
Copy link
Author

uberger commented Nov 30, 2023

Indeed, if I don't use id as a property in the JSON string (as you did in your example with msg.id) the Azure Storage Queue message ID is not overwritten and is accessible in the main function.

My problem is, that the design of the JSON string is outside of my control. The message I receive will definitely contain a JSON item with the name id. Then, the Azure Storage Queue message ID is lost to me. To me this doesn't appear to be intentional behavior and that's why I raised this bug report.

@hallvictoria
Copy link

Hey @uberger thanks for your patience. I looked into this issue and here are some things that I found:

  • This error only occurs for Queue messages with content in dictionary / JSON format
  • The message content is added as part of the object's metadata dict. When the content is in JSON format, those fields are also added as key-value pairs in the object metadata thus overwriting other attributes of the same name
  • In this case, the id attribute was being overwritten, but it can also occur for any other attribute (e.g. PopReceipt)

Need the extension team to check and see how this can be addressed

@hallvictoria hallvictoria transferred this issue from Azure/azure-functions-python-worker Dec 9, 2023
@Zzappy24
Copy link

Zzappy24 commented Jan 12, 2025

Hello, I had the same issue, and I found a work around.
You could use context.invocation_id like this:

@app.queue_trigger(arg_name="azqueue", queue_name=queue, connection="AzureWebJobsStorage") def queue_trigger(azqueue: func.QueueMessage, context: func.Context): id_message_queue = context.invocation_id

@uberger
Copy link
Author

uberger commented Jan 13, 2025

Hi, @Zzappy24 , thanks for your contribution. I also use the context.invocation_id to trace a job throughout the function app. I still desire to to link the (message) ID that an Azure Storage Queue client receives after adding an item to the queue. Of course msg.id != context.invocation_id, thus the link between queue client and function app invocation gets lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants