Are you saying _unit becomes a number? Cannot happen by design, you can prove the engine wrong by adding a repro to this ticket.

Cannot happen by design, you can prove the engine wrong by adding a repro to this ticket.

Unfortunately, I have no enough skills to reproduce it in editor, it can only be reproduced in my mission, and I understand that it would be very hard for devs to reproduce it without knowing such info.

you can prove the engine wrong

I think the log entry is enough to prove that something goes wrong :)

Well you can post your entire mission with all the scripts so the devs can investigate the scripts directly.

I think the log entry is enough to prove that something goes wrong :)

Not unless you do something wrong. (which is why posting your scripts will help)

Not unless you do something wrong. (which is why posting your scripts will help)

Depends on what do you mean under "doing wrong". If it means just creating GetIn EH according to official wiki, and getting weird results, then I don't think I'm doing it wrong :)

Well you can post your entire mission with all the scripts so the devs can investigate the scripts directly.

If someone really interested, I can communicate with him directly to help to investigate that issue - but it is large in size.
https://steamcommunity.com/sharedfiles/filedetails/?id=1972510873
I can prepare the save and scripting commands to recreate the situation.

Depends on what do you mean under "doing wrong"

for example we had a very similar report when EH supposedly fired with params of another EH. As it happened the mission maker called function from EH which through some script error was also called from another EH. So unless you have a repro, not much we can do.

As it happened the mission maker called function from EH which through some script error was also called from another EH

In my case, the EH added in CBA FrameHandler cycle. I have already encountered a couple of serious bugs in CBA functions, and more than once I regretted using them in complex scripts.
The first one: https://github.com/CBATeam/CBA_A3/issues/1570#issuecomment-1465218758
The second one happened in the same PFH loop, just a bit above:

{
	private _idx = 0; // A "flag" to detect the first and the second vehicle
	{
		private _cls = _x;
		if (_cls isKindOf "LandVehicle") then {
			if (_idx == 0) then {
				_veh = createVehicle [_cls, [3274.82,12969.3,0.110337], [],0, "CAN_COLLIDE"];
				_veh setdir 178;
				// Here _idx is still 0
				[_veh,grpNull] call OT_fnc_veh_replace; // A large procedure to preapre the vehicle
				// And here **_idx becomes -1**!
				_idx = _idx + 1;
			} else {
				_veh = createVehicle [_cls, [3260.0,12969.0,0.110337], [],0, "CAN_COLLIDE"];
				_veh setdir 178;
				[_veh,grpNull] call OT_fnc_veh_replace;
			};
		} else {
			// the remaining code (it has no _idx reference at all)	
		};
	};
} foreach [two vehicle classes to spawn amongst other stuff];

So I think I need to rework the loop, using only standard methods.

So unless you have a repro, not much we can do.

I have a repro, but it needs the mission to be loaded with all requirements :)
Anyway, if it turns out to be the CBA's issue, then, most likely, it has no sense.

Added:
I've reworked the script, the issue with -1 I mentioned above is gone, but the EH still see the number instead of unit. So CBA is not the cause in this case.

I have a feeling you're not privateing your vars, causing them to be changed by an inner function.

If you mean the -1 issue - as you can see, all variables "privated" correctly, and there are no such variable names in upper scopes.
Also I mentioned that variables changes after the function call.
Current CBA realease has some problems with variables scopes - see the link above.

As CBA devs pointed out to you, it's not a CBA issue.

As I described in the ticked, it happens ONLY in CBA functions.
If it is not a CBA function bug for any reason, then it is the bug of CBA + something, so it may be important only for CBA developers, not for debugging from my side.