MIP SDK hung forever on bad credentials (Linux)

Tamir Aviv 0 Reputation points
2026-05-22T18:17:23.1566667+00:00

Minimal repro to include:

  • MIP SDK version: 1.18.124 (mip_sdk_file_ubuntu2404_1.18.124.tar.gz) - the latest version
  • Platform: Ubuntu 24.04 x86_64 (also reproduced on Apple Silicon under emulation inside a docker)
  • Code path: AddEngineAsync → SDK calls AuthDelegate::AcquireOAuth2Token → delegate returns false with OAuth2Token::SetErrorMessage(...) populated
  • Expected: FileProfile::Observer::OnAddEngineFailure fires with NoAuthTokenError
  • Actual: observer never fires; the std::promise passed to AddEngineAsync is never resolved; the matching std::future::get() hangs forever
  • Works correctly on macOS arm64 with the same code and the macOS 1.18.124 build of the SDK

The problem:

When I try to use the mip sdk inside a docker container (FROM ubuntu), and provide a bad credentials to the SDK, the SDK hung forever. But when I do the same in MacOS - the code is successful.

Here are some logs I added for me calls:

In Linux:

mip_label: initialize: starting (storage_path=, use_online_mode=1)                                                                                                        
mip_label: initialize: building MipConfiguration                                                                                                                          
mip_label: initialize: calling MipContext::Create                                                                                                                         
mip_label: initialize: MipContext::Create returned                                                                                                                        
mip_label: initialize: creating FileProfile                                                                                                                               
mip_label: createProfile: FileProfile::LoadAsync                                                                                                                          
mip_label: createProfile: waiting on future                                                                                                                               
mip_label: ProfileObserver::OnLoadSuccess                                                                                                                                 
mip_label: createProfile: future RETURNED                                                                                                                                 
mip_label: initialize: FileProfile created                                                                                                                                
mip_label: initialize: SUCCESS

mip_label: getDecryptedTemporaryStreamAsync: ENTER file_name=dummy..docx size=50688 tenant_id=51d026a2-b24d-4ea2-b475-f3ca69162cc2 client_id=3eb766ef-0095-4a55-a356-c4a3cd59444b                                                                                                                            
mip_label: decrypt: building CallbackFileStream                                                                                                                           
mip_label: decrypt: getOrCreateAuthDelegate                                                                                                                               
mip_label: decrypt: createFileEngine engineId=3eb766ef-0095-4a55-a356-c4a3cd59444b                                                                                        
mip_label: createFileEngine: AddEngineAsync engineId=3eb766ef-0095-4a55-a356-c4a3cd59444b                                                                                 
mip_label: createFileEngine: waiting on future                                                                                                                            
mip_label: AcquireOAuth2Token: resource=https://syncservice.o365syncservice.com/ authority=https://login.windows.net/common scope=                                        
mip_label: get_or_create_token: resource=https://syncservice.o365syncservice.com/ client_id=3eb766ef-0095-4a55-a356-c4a3cd59444b                                          
mip_label: get_or_create_token: cache miss, calling get_token (HTTP)                                                                                                      
mip_label: get_token: POST https://login.windows.net/51d026a2-b24d-4ea2-b475-f3ca69162cc2/oauth2/token                                                                    
mip_label: get_token: curl res=0 http_code=400

You can see here that it failed with 400, and just got stuck, no more logs after that and the process hung.

In MacOs on the other hand:

mip_label: initialize: starting (storage_path=, use_online_mode=1)
mip_label: initialize: building MipConfiguration
mip_label: initialize: calling MipContext::Create
mip_label: initialize: MipContext::Create returned
mip_label: initialize: creating FileProfile
mip_label: createProfile: FileProfile::LoadAsync
mip_label: createProfile: waiting on future
mip_label: ProfileObserver::OnLoadSuccess
mip_label: createProfile: future RETURNED
mip_label: initialize: FileProfile created
mip_label: initialize: SUCCESS

mip_label: getDecryptedTemporaryStreamAsync: ENTER file_name=dummy..docx size=50688 tenant_id=51d026a2-b24d-4ea2-b475-f3ca69162cc2 client_id=3eb766ef-0095-4a55-a356-c4a3cd59444b
mip_label: decrypt: building CallbackFileStream
mip_label: decrypt: getOrCreateAuthDelegate
mip_label: decrypt: createFileEngine engineId=3eb766ef-0095-4a55-a356-c4a3cd59444b
mip_label: createFileEngine: AddEngineAsync engineId=3eb766ef-0095-4a55-a356-c4a3cd59444b
mip_label: createFileEngine: waiting on future
mip_label: AcquireOAuth2Token: resource=https://syncservice.o365syncservice.com/ authority=https://login.windows.net/common scope=
mip_label: get_or_create_token: resource=https://syncservice.o365syncservice.com/ client_id=3eb766ef-0095-4a55-a356-c4a3cd59444b
mip_label: get_or_create_token: cache miss, calling get_token (HTTP)
mip_label: get_token: POST https://login.windows.net/51d026a2-b24d-4ea2-b475-f3ca69162cc2/oauth2/token
mip_label: get_token: curl res=0 http_code=400
mip_label: AcquireOAuth2Token: resource=https://syncservice.o365syncservice.com/ authority=https://login.windows.net/common scope=
mip_label: get_or_create_token: resource=https://syncservice.o365syncservice.com/ client_id=3eb766ef-0095-4a55-a356-c4a3cd59444b
mip_label: get_or_create_token: cache miss, calling get_token (HTTP)
mip_label: get_token: POST https://login.windows.net/51d026a2-b24d-4ea2-b475-f3ca69162cc2/oauth2/token
mip_label: get_token: curl res=0 http_code=400
mip_label: ProfileObserver::OnAddEngineFailure
mip_label: decrypt: NoAuthTokenError what=Client application failed to provide authentication token for HTTP request. Failed with: [HTTP response code: 400: 'HTTP response code: 400'], RMS Response=Empty response body, CorrelationId=ed9a7d09-5f0c-47e3-a193-30f42eb6dcbe, CorrelationId.Description=PolicyProfile

It continued with a proper error.

Just to make it super clear, it happen even when the implementation of AcquireOAuth2Token is:

 bool AuthDelegateImpl::AcquireOAuth2Token(...)                                                                                                                            
  {                                                                                                                                                                         
      token.SetErrorMessage("test stub");                                                                                                                                   
      return false;                                                                                                                                                         
  }

So it is related to something internal in the MIP sdk.

Can you please check it out?

Thanks,

Tamir Aviv

Community Center | Not monitored
0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-05-22T18:17:43.35+00:00

    This behavior is consistent with how the MIP SDK surfaces authentication failures and exceptions, but the specific Linux hang with bad credentials is not documented in the provided content and cannot be fully diagnosed or confirmed as a known issue from it.

    From the available information, the following points are relevant:

    1. The MIP SDK uses an AuthDelegate implementation to acquire OAuth2 tokens. The SDK calls mip::AuthDelegate::AcquireOAuth2Token() and expects the delegate to either:
      • Successfully acquire a token and populate OAuth2Token, or
      • Fail and indicate that failure via the OAuth2Token object and the return value.
      The SDK itself is responsible for calling AcquireOAuth2Token and then continuing engine creation or surfacing an error.
    2. In current documentation, authentication is described as:
      • The SDK calls AcquireOAuth2Token when required.
      • The delegate writes the token result into OAuth2Token.
      • The SDK consumes that result when loading the engine.
      The documented contract is that the app does not call AcquireOAuth2Token directly and that token acquisition logic must be implemented correctly in the delegate.
    3. The documented exception for missing tokens is mip::NoAuthTokenError, which is thrown when the application's AuthDelegate returns an empty token (for example, due to cancellation). This is the error expected to be surfaced to the application when authentication fails and no usable token is provided.
    4. The version history and FAQs in the provided content do not list a known issue for Linux or Docker where AddEngineAsync hangs indefinitely when the delegate returns failure or a bad token. There is no documented platform-specific difference between macOS and Linux behavior for this scenario in the referenced materials.

    Given the constraints of the available documentation, the only actionable guidance that can be derived is:

    • Ensure the AuthDelegate::AcquireOAuth2Token implementation strictly follows the documented contract: on failure, it should clearly indicate the failure via the OAuth2Token object and the return value, and not leave the token in an indeterminate state.
    • Confirm that the application is not blocking or deadlocking inside AcquireOAuth2Token itself on Linux (for example, via network, threading, or synchronization differences in the container environment), since the SDK depends on that method returning in order to proceed and eventually raise NoAuthTokenError.
    • Verify that the application is built and linked against the correct Linux dependencies for the MIP SDK as documented (curl, OpenSSL, libsecret, etc.), and that the runtime environment in Docker matches those expectations.

    However, whether this specific hang is a product bug in the Linux 1.18.124 build or an environment/implementation issue cannot be determined from the provided content.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.