Under what circumstances would wordpress_logged_in NOT be sent?

I have written non-web-browser based series of applications that I have sold for the past 6 odd years now. It starts by contacting a WordPress website with login credentials and then saving the cookie locally to be sent back with every future WordPress contact.

These apps of mine have worked just fine for almost everybody but every now and then I get a user who just can’t login and when I inspect their site’s response headers I see PHPSESSID and some time jetpack cookies but no wordpress_logged_in cookie.

In some cases we discovered that certain plugins cause this to happen and so we contacted the plugin author to ask why is plugin prevents WordPress from sending out that cookie and in all cases they swear high and low they don’t touch it. Looking through their code I can’t see any obvious thing they do that might affect it and yet the fact remains that my kit receives the cookie whenever their plugin(s) are disabled and it ceases to do so when the plugin is enabled.

Another thing I see very often when this happens is that they are running IGINX so I have come to believe that is the issue whenever I see it. Tonight I have yet another customer (first one in ages) to have this problem. Again, running IGINX and sent cookies are only PHPSESSID and jetpack.

If plugin authors can prevent WordPress from sending out that cookie without even knowing they are doing so… does anyone have any idea what might be causing this to happen? Is there a filter or hook they need to call to send that out if they remove another filter or hook or something like that or will WordPress always be in charge of sending that out?

I guess that is the main thing I need to know. What could cause WordPress to NOT send out that cookie and what can I do to make sure it DOES send it?

Thanks