This bug is especially difficult to test in actual working conditions, because it needs:

1. The application running with at least 2 users
2. both users must be connected to the same entity (corporation in the ERP)
3. both users must try all 4 instances to generate the posted events
4. the error log of the server serving the application must be monitored to check for the actual values being returned by PHP

The values need to be a PHP problem simply because they are the result of Firebird Triggers after insert/delete which are definitely doing what they are supposed to do, as they have been checked with the same function, one by one.

the instruction in PHP:

$ev = ibase_wait_event($rsc,$ev1,$ev2);

Is now capable of receiving properly ONLY the first event in the list that the function is supposed to accept. In this case, $ev2 will never be transferred as a value to $ev.

This is a serious matter and it needs to be fixed ASAP; there might be a number of applications receiving messages from the server; such messages are generated as the ibase_wait_event() function DOES RECEIVE an event call from the Firebird database.

What happens now is that all those “servers” running, will remain running even long after the client has been disconnected, because the only way for them to die is by trying to send the client a message and NOT FINDING the client.

ibase_wait_event stops execution of the PHP task and remains idle until Firebird does POST an event.

So, it is mandatory that this function works properly for Firebird SQL server to be fully functional with PHP programming.

This is the ibase php version that is failing to properly catch and retrieve the events sent by the database:5.4.6-0ubuntu5.

This is ONE work-around (it the case of 4 events):

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
$idu=$_REQUEST["idu"];
$idc=$_REQUEST["idc"];
$con = ibase_connect(...) or die(json_encode(array("Error"=>ibase_errmsg())));
$ev0="noev0"; $ev01="noev01"; $ev02="noev02"; $ev03="noev03"; $ev04="noev04"; $ev05="noev05"; $ev06="noev0";
$ev1="newmsgi".$idu;
$ev2="usrin".$idc;
$ev3="usrout".$idc;
$ev4="chat".$idu;
$ev = ibase_wait_event($ev1,$ev0,$ev2,$ev01,$ev3,$ev02,$ev4);
error_log("Evento regresado el idu ".$idu." idc ".$idc.": ".$ev);
/* $ev1 = $ev1
   $ev0 = $ev2
   $ev2 = $ev3
   $ev01 = $ev4 */
switch($ev){
case $ev1:
	$sql="sata: {$m}\n\n";
			flush();
		}
break;
case $ev0:
	$sql="select f
	flush();
break;
case $ev2:
	$sql="sel
	flush();
break;
case $ev01:
	$sql="sele
	flush();
break;
}

?>

as you can see in the code above, the REAL events the database Firebird sends are:

$ev1, $ev2, $ev3 and $ev4

However, ibase_wait_event receives them in a different order:
$ev1 goes to $ev1 (no change)
$ev2 goes to $ev0 (3rd goes to 2nd)
$ev3 goes to $ev2 (5th goes to 3rd)
$ev4 goes to $ev01 (7th goes to 4th)

There is a patter there; but this is about catching events, not about figuring out patterns.

Is there somebody in the world in charge of fixing this bug?

Otherwise, where is the source?

> Is there somebody in the world in charge of fixing this bug?

Apparently, not (yet). It might be useful if you can make a patch
or even better a pull request.

> Otherwise, where is the source?

The source of the interbase extension is available via Github:
<https://github.com/php/php-src/tree/master/ext/interbase>.

The interbase extension is moved to PECL[1] as of PHP 7.4.0, and
is looking for a new maintainer.  Until a new maintainer is found,
I suspend this ticket.

Consider to use the bundled PDO_Firebird extension, or the
php-firebird package[2] instead.

[1] <https://pecl.php.net/package/interbase>
[2] <https://github.com/FirebirdSQL/php-firebird>