Forum Discussion

ruhanO300's avatar
ruhanO300
Copper Contributor
Jul 18, 2024

Cannot create new subscription to resource

APP BACKGROUND

I have an app that integrate with Microsoft Graph API in order to create subscriptions for some resources.

In order to keep subscriptions valid for a long period, I have to update it to continue receiving change notifications on these resources.

Basically my workflow for refresh a subscription is:

 

ISSUE

This process works well the most part of the time, but during some hours ( generally during 1~3h) on random days, it stop to work for some random resources.
Basically I receive a 404 status from Microsoft when trying to patch or delete the subscription (which is expected on this case), but when I attempt to create a new subscription it returns a 403 error saying:

 

Operation: Create; Exception: [Status Code: Forbidden; Reason: App 'aaaa-bbbb-cccc-dddd-ffff' has reached its limit of '1' 'USERS/AAAAA-BBBB-CCCC-DDDD-EEEE/CHATS/GETALLMESSAGES' subscription on tenant 'aaaaa-hhhhhh-jjjj-uuuu-zzzz

 


How could the subscription already exists if previously it returned a 404 saying that it doesn't exists?

SAMPLE REQUEST ID

Following the request id a sample of this issue:

developer
microsoft teams
  • muhammad_kekereekun's avatar
    muhammad_kekereekun
    Iron Contributor
    Jul 18, 2024

    ruhanO300 

    The issue you're encountering with the Microsoft Graph API subscriptions seems to be a race condition between the PATCH/DELETE and the subsequent POST request. Here's why:

    • 404 on PATCH/DELETE: This suggests the subscription might be already deleted or expired, hence the "Not Found" response.
    • 403 on POST (limit reached): This indicates your app has reached the limit of allowed subscriptions for a specific resource type ("USERS/AAAAA-BBBB-CCCC-DDDD-EEEE/CHATS/GETALLMESSAGES") on the specific tenant.

    Possible Explanation:

    • There might be a delay between your PATCH/DELETE request and the updated subscription information propagating across Microsoft's servers.
    • By the time your POST request arrives, the subscription might still be considered "active" within the quota system, even though your previous attempt logically deleted it.

    Solutions:

    1. Increase Subscription Lifetime: If possible, configure your subscriptions with a longer expiry time (within allowed limits) through the expirationDateTime property in the PATCH request. This reduces the frequency of refresh attempts and minimizes the chance of encountering the race condition.

    2. Exponential Backoff: Implement an exponential backoff strategy for your retry logic. This means waiting a progressively longer period before retrying the POST request after a 403 error. This gives Microsoft's servers more time to update the subscription information and avoid hitting the quota limit right away.

    3. Single PATCH/POST Call: Consider combining the PATCH and POST functionalities into a single API call (if supported by the specific resource type). This eliminates the race condition entirely. However, check the Microsoft Graph documentation for availability of such a combined endpoint.

    Additional Tips:

    • Utilize the provided request IDs (f5504a6c-b571-4ee4-893c-b96aae64a759, 1d3c601d-f761-43f2-8260-c30bf7a3540e, c06196f7-d3c2-4a7d-8e7b-6fc9d63ec496) to investigate further through the Microsoft Graph activity logs. This might reveal additional details about the subscription status changes.
    • Consider increasing the logging level in your app to capture more details about the request/response cycle, including timestamps and the subscription ID, to analyze the exact timing of the issue and refine your retry logic.

    By implementing some of these strategies, you should be able to mitigate the race condition and ensure smooth subscription refresh for your Microsoft Graph API integration.

    Kindly confirm if this information proves useful to you.

    Thanks very much for choosing Microsoft.

Resources