Polling/Notification errors after upgrading PHP from 7.2 to 7.4

[bandtank]

I upgraded my server from PHP 7.2 to 7.4 and the CRM site works for the most part, but I continuously see "Bad Server Request" due to popNotifications and notReadCount requests. The server is returning the literal code/text of the api/v1/index.php file instead of executing it. However, php files otherwise appear to work without issue. I created a file called test.php at the root of each site to execute phpinfo(), which works as expected.

There are two EspoCRM sites running on my server:

• EspoCRM 5.5.6, Advanced Pack 1.33.8
• EspoCRM 5.9.3, No extensions

Both sites are doing the same thing, so I don't think it is related to site configuration. Cron is working (emails are being sent), both sites load and read/write the database, websockets are not enabled, and external tools which use the EspoCRM API are working (responses are returned normally, data is good, etc.). I don't know what's wrong or what to try because nothing is appearing in any of the log files (Espo, Apache, etc.).

It must be related to the PHP 7.4 installation or the removal of PHP 7.2. The error didn't appear until I removed PHP 7.2, which I did after PHP 7.4 had been installed. The server requirements pages in EspoCRM show no issues or errors, but it's like the notification/polling requests are trying to use an old version of PHP which no longer exists.

Any help would be greatly appreciated.

Apache2 Modules:

$ sudo apachectl -M
Loaded Modules:
core_module (static)
so_module (static)
watchdog_module (static)
http_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
unixd_module (static)
access_compat_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
filter_module (shared)
headers_module (shared)
mime_module (shared)
mpm_prefork_module (shared)
negotiation_module (shared)
php7_module (shared)
reqtimeout_module (shared)
rewrite_module (shared)
setenvif_module (shared)
socache_shmcb_module (shared)
ssl_module (shared)
status_module (shared)

The first section of phpinfo():

 [TABLE]
[TR]
[TD]System[/TD]
 			[TD]Linux pse-crm 5.3.0-1028-aws #30~18.04.1-Ubuntu SMP Mon Jun 22 15:48:21 UTC 2020 x86_64[/TD]
 		[/TR]
[TR]
[TD]Build Date[/TD]
 			[TD]Jun 12 2020 07:44:05[/TD]
 		[/TR]
[TR]
[TD]Server API[/TD]
 			[TD]Apache 2.0 Handler[/TD]
 		[/TR]
[TR]
[TD]Virtual Directory Support[/TD]
 			[TD]disabled[/TD]
 		[/TR]
[TR]
[TD]Configuration File (php.ini) Path[/TD]
 			[TD]/etc/php/7.4/apache2[/TD]
 		[/TR]
[TR]
[TD]Loaded Configuration File[/TD]
 			[TD]/etc/php/7.4/apache2/php.ini[/TD]
 		[/TR]
[TR]
[TD]Scan this dir for additional .ini files[/TD]
 			[TD]/etc/php/7.4/apache2/conf.d[/TD]
 		[/TR]
[TR]
[TD]Additional .ini files parsed[/TD]
 			[TD]/etc/php/7.4/apache2/conf.d/10-mysqlnd.ini, /etc/php/7.4/apache2/conf.d/10-opcache.ini, /etc/php/7.4/apache2/conf.d/10-pdo.ini, /etc/php/7.4/apache2/conf.d/15-xml.ini, /etc/php/7.4/apache2/conf.d/20-calendar.ini, /etc/php/7.4/apache2/conf.d/20-ctype.ini, /etc/php/7.4/apache2/conf.d/20-curl.ini, /etc/php/7.4/apache2/conf.d/20-dom.ini, /etc/php/7.4/apache2/conf.d/20-exif.ini, /etc/php/7.4/apache2/conf.d/20-ffi.ini, /etc/php/7.4/apache2/conf.d/20-fileinfo.ini, /etc/php/7.4/apache2/conf.d/20-ftp.ini, /etc/php/7.4/apache2/conf.d/20-gd.ini, /etc/php/7.4/apache2/conf.d/20-gettext.ini, /etc/php/7.4/apache2/conf.d/20-iconv.ini, /etc/php/7.4/apache2/conf.d/20-imagick.ini, /etc/php/7.4/apache2/conf.d/20-imap.ini, /etc/php/7.4/apache2/conf.d/20-json.ini, /etc/php/7.4/apache2/conf.d/20-mbstring.ini, /etc/php/7.4/apache2/conf.d/20-mysqli.ini, /etc/php/7.4/apache2/conf.d/20-pdo_mysql.ini, /etc/php/7.4/apache2/conf.d/20-phar.ini, /etc/php/7.4/apache2/conf.d/20-posix.ini, /etc/php/7.4/apache2/conf.d/20-readline.ini, /etc/php/7.4/apache2/conf.d/20-shmop.ini, /etc/php/7.4/apache2/conf.d/20-simplexml.ini, /etc/php/7.4/apache2/conf.d/20-sockets.ini, /etc/php/7.4/apache2/conf.d/20-sysvmsg.ini, /etc/php/7.4/apache2/conf.d/20-sysvsem.ini, /etc/php/7.4/apache2/conf.d/20-sysvshm.ini, /etc/php/7.4/apache2/conf.d/20-tidy.ini, /etc/php/7.4/apache2/conf.d/20-tokenizer.ini, /etc/php/7.4/apache2/conf.d/20-xmlreader.ini, /etc/php/7.4/apache2/conf.d/20-xmlrpc.ini, /etc/php/7.4/apache2/conf.d/20-xmlwriter.ini, /etc/php/7.4/apache2/conf.d/20-xsl.ini, /etc/php/7.4/apache2/conf.d/20-zip.ini, /etc/php/7.4/apache2/conf.d/20-zmq.ini[/TD]
 		[/TR]
[/TABLE]

[bandtank]

Update: I have no idea why this helped, but I did a hard cache clear in Chrome and the notification request began to work as expected.

The return value of the request is now '0' instead of the code in the api/v1/index.php file. I thought something may have been going wrong because I added a commented out statement in api/v1/index.php, which was not being shown in the return value of the request. I cleared EspoCRM's cache, Apache's cache (htcacheclean), and every other cache I could find to no avail. Nuking Chrome's cache seems to have worked it out, but this is a big problem because my users will not know how to do a hard reset of Chrome's cache even with instructions.

The underlying issue has not been addressed and I'm still trying to figure out what it is.