Lines 758 and 769 in file tr_status.php for version 2.2.4 (as downloaded from zabbix.com) do not have array element access with indexes reported in error message.
Could you answer following:
1) Which version exactly (and from where) is used?
2) How can the error be repeated?

Now is not a problem. Message on the page triggers missing.
Code tr_status.php 758 and 759

'eventid='.$trigger['lastEvent']['eventid'].
'&triggerid='.$trigger['lastEvent']['objectid'].

Version 2.2.4 with our minor modifications

We could not reproduce. More detailed explanation on how to repeat this behavior is necessary to proceed.

If problem comes back, please supply more info.

Well, I have the same errors on vanilla frontend 2.2.4, errors are:

Undefined index: eventid [ in /var/www/html/tr_status.php:726] 
Undefined index: objectid [ in /var/www/html/tr_status.php:727]

I know that such errors appear for triggers which were acknowledged.

I don't have direct access to the frontend so it will take some time to figure out why these errors appear.
Stay tuned.

There is confirmation that this issue appeared after 2.2.4 upgrade.

I accidentally was able to "reproduce" it when worked on another issue ZBX-8499.
To be correct - I reproduced it after I manually changed some values in events table, so it's not very correct approach but it may help to find out root cause.

It's reproducible after changes in ZBX-7983.
Before the change frontend generated SQL:

SELECT e.* FROM events e WHERE e.objectid='13575' AND e.object='0' AND e.source='0' ORDER BY e.clock DESC,e.eventid DESC LIMIT 1 OFFSET 0

after:

SELECT e.* FROM ( SELECT e2.objectid,MAX(e2.clock) AS clock,MAX(e2.eventid) AS eventid FROM events e2 WHERE e2.object=0 AND e2.source=0 AND e2.objectid='13575' GROUP BY e2.objectid) e2, events e WHERE e.objectid=e2.objectid AND e.clock=e2.clock AND e.eventid=e2.eventid

In my tests I changed clock order to last or previous events (triggerid=13575) in a way that event with highest ID has clock which is less than previous event.
Practice shows that it's really possible in production (investigated in ZBX-8499 I mentioned above).

In case when I changed the clock manually - the new SQL returns empty result and then we can see those Undefined index errors.
Old SQL selected an event with highest clock.

BUT, from the production frontend I mentioned in previous comment I got saved html pages and I see there only correct order of eventIDs and their clock but the Undefined index errors are there as well.
So my test case is not single way to reproduce it, but I still don't know how how.

Evgeny, is it possible that you will save the page as html and attach it here (or send it to an email)?

I have more details on my case. Please wait.

In my "production case" issue appeared because that installation "migrated" from DM to standalone mode in manual fashion - as described bottom of ZBX-7829.
In events table are events with IDs like 100100000000002 but timestamp are close to "12 Feb 2014" (when DM was migrated to standalone).
Currently server creates events with Ids like 1483798 with current time stamps.

So it's the same case as I emulated in previous comment.

But, if we consider NEW zabbix code:

$dbEvents = DBselect(
				'SELECT '.$outputFields.
				' FROM ('.
					' SELECT e2.objectid,MAX(e2.clock) AS clock,MAX(e2.eventid) AS eventid'.
					' FROM events e2'.
					' WHERE e2.object='.EVENT_OBJECT_TRIGGER.
						' AND e2.source='.EVENT_SOURCE_TRIGGERS.
						' AND '.dbConditionInt('e2.objectid', $triggerids).
					' GROUP BY e2.objectid'.
				') e2, events e'.
				' WHERE e.objectid=e2.objectid'.
					' AND e.clock=e2.clock'.
					' AND e.eventid=e2.eventid'
			);

we don't see any limitation for nodeID.
Imagine that it's a master node=1 with received events from child=2.
I suppose it should give the same result as my experiment.

added:
Currently standalone zabbix server 2.2 searches max eventID in this way:

 29237:20140723:161835.787 In process_events() events_num:1
 29237:20140723:161835.788 In DCget_nextid() table:'events' num:1
 29237:20140723:161835.788 query [txnlev:1] [select max(eventid) from events where eventid between 0 and 99999999999999]

So standalone server didn't notice outdated events from period when this server worked as node.

Interesting, I'm not sure but I think it will be true also after migration to 2.4
https://www.zabbix.com/documentation/2.4/manual/introduction/whatsnew240#node-based_distributed_monitoring_removed

Yeah, tested DM installation on 2.2.6rc1 and I see that frontend produces that SQL (new code) w/o nodeID limitations:

SELECT e.* FROM ( SELECT e2.objectid,MAX(e2.clock) AS clock,MAX(e2.eventid) AS eventid FROM events e2 WHERE e2.object=0 AND e2.source=0 AND e2.objectid='100100000013557' GROUP BY e2.objectid) e2, events e WHERE e.objectid=e2.objectid AND e.clock=e2.clock AND e.eventid=e2.eventid

when all other SQLs with the limitations.

We started to forged about nodes too early

In ZBX-8556 is a scenario how to reproduce described events order.

[S] Fix implemented at svn://svn.zabbix.com/branches/dev/ZBX-8424

In the dev branch server does this SQL to search max eventids:
query [txnlev:1] [select max(eventid) from events where eventid between 0 and 9223372036854775807]

According to svn log message.

Server side's fix merged in pre-2.2.6 r47725.

(2) Frontend code requires modification.

iivs RESOLVED in svn://svn.zabbix.com/branches/dev/ZBX-8424 r47795

sasha CLOSED

Finding last event for triggers is now fixed in frontend.

Fixed in pre-2.2.6rc1 r47812 and pre-2.3.3 r47813

(5) Please update the API changelog. A more detailed entry would be preferable.

iivs Changes described here https://www.zabbix.com/documentation/2.2/manual/api/changes_2.2?do=diff&rev2[0]=1408108783&rev2[1]=&difftype=sidebyside
I moved from "other changes" to "bug fixes" like discussed.

jelisejev Thanks, CLOSED.