AlexaCRM/dynamics-webapi-toolkit

CRM API methods (create, update) stalls

alienzed opened this issue · 6 comments

Describe the bug
We have a process that creates two new contacts and links them in CRM using an entity reference field. We see intermittent failures without any error being thrown, the process simply stops after a Create or Update call to the client. The resulting operation typically does appear to complete (i.e. the record is in fact created) but the rest of the PHP script does not execute and any follow up tasks remain incomplete.

To Reproduce
Create a new Contact, set attributes, call Create, sometimes the script stops here (without any error being thrown). Sometimes it gets past this step and creates a second contact, which can stall. Sometimes it gets past that step and then I reload the initial contact and set it's Reference and then call Update and this step NEVER completes.

Expected behavior
Calls to Create and/or Update should succeed or at least throw an error (time out, bad field, anything!) if they do not complete.

Additional context
CRM is responding quite slowly, sometimes taking up to 10 seconds to create a single record, so I do wonder if there are timeouts set too low. I've added a PSR-3 compliant logger (Drupal 8) but this is not showing any errors either, just when POST and GET requests complete propely.

Ultimately I need to find out what is causing the process to halt, to see the error or other know how to change my configuration in order to get a lead. Currently we're seeing inconsistent behaviour and no clue as to why things aren't completing properly.

Please note that I had previously been using the SOAP based version of this library and have recently migrated to use this WEB API version, this problem did start roughly around the same time we migrated, so that's noteworthy.

Thank you for any and all assistance and thank you so much for this wonderful library.

@alienzed thanks for the detailed bug report. To investigate further we need the offending code + corresponding logs. We would also need the detailed information about your environment, including hosting OS and components versions. We use Guzzler as our HTTP library so perhaps that could help to further investigate the problem. Certainly, execution shouldn't just stop but there are so many permutations between different components that it's impossible to investigate using the information provided.

Have you tried your code in isolation, outside of Drupal? That'd be a good test to check if it's a specific environmental issue.

Slow responses from CRM deserve a separate investigation. I would try the equivalent methods in Postman just to see what the low level response times are. Perhaps it's the presence of the plugins that causes the issue, perhaps it's the latency, perhaps something else.

Excellent tips... as for the code and environment I could certainly provide that, although our process isn't trivial :/

As for trying the code in isolation, that's a good idea but easier said than done as I built out a large chunk of the functionality to tie into Drupal... Those calls/integrations do work well though. It occurred to me today that I could add more debugging logic to a copy of this code base to debug more. You also mention Guzzler, any tips on debugging that?

As for CRM, unfortunately we know it is slow and sort of know why and also probably can't do much about it, but I have asked that side to optimize as much as possible.

Can you tell me though... Does this API have any sort of preset timeout or memory limit or something that would cause the script to just... stop processing. What could be happening in this library that the very next call in my PHP script after $client->Create or $client->Update never gets called and no errors are written anywhere?

Guzzler does have hooks into PSR-3 compliant loggers so you can definitely look into using that for extensive logging.

CRM is not meant to be slow to the tune of 10 sec to create a record - there must be something else going on.

We do not have any implicit timeouts in place. CRM/Dataverse timeouts would be around 2 min and 10 seconds calls shouldn't cause any drama. In any case, you should be getting an error on timeout, not just "stopping" behaviour.

All in all, it does sound like further investigation is needed, isolating the problem would be a good start.

Absolutely. This issue is causing persistent issues for my client so we will get to the bottom of it... I'll look into more logging hooks and other debugging strategies, but short of doing a Zoom call with you and showing you what happens I'll just have to keep plugging away. If I do find a bug or issue with this library I will gladly let you know and contribute the fix. I'm still not sure this is not a CRM problem though...

@alienzed I appreciate the thought but we can provide direct support only on t&m basis. For the open source project we would engage as our availability allows and only if the problem is reproducible on our end. Hope you understand.

Of course! And if ever we did want assistance we would certainly not expect it to be free. Let me see what I can find, if you want to close the issue so that it is not cluttering up your queue, I'll understand.

Thank you and happy holidays!