Deniz Mert Edincik

@sideninja yeah that was my fix I remember the contract ( typeID cadence ) maybe cadence changed something ? it was hacky fix PS: yeah we fixed for legacy `typeID`,...

@SupunS yeah I made the fix for one level, but rest got complicated, I did not feel comfortable copying that much.

@SupunS , actually it works, thanks a lot. I didn't know about event.Payload. PS: made a PR

`flow transactions get 16de57b007aa44dee2280231e7490a420f0f1c34b2212f438b74c156636553c8 -n mainnet -o json - endless no return` this one can be related to AN I guess

@fyrz I think that transaction somehow does not exist in the AN, so CLI thinks it is just sent and waiting for it to be sealed. But someone from flow...

> Just want to note that this would require a change to the view function feature: currently emitting an event is considered a non-view operation. This wouldn't block this feature,...

> Are we OK though with how this feature (emitting events from conditions) would be used? In the example, the event emission function (emitTokenWithdrawal) can be called by any code,...

How can it be called with `Type()`? ```cadence access(contract) fun emitTokenWithdrawal(type: Type, amount: UFix64, from: Address?): Bool{ emit TokenWithdrawal(type:type, amount:amount, from:from) return true } ``` This is only called from...

> Here, ExampleFT.Deposit is a FT.Deposit event, and only code in ExampleFT can emit the event. If some code declares an event Deposit, it has no relation to FT.Deposit. So,...

Yeah it is a valid point, but safety part I didn’t get; eventually if you implement some interface, this interface enforcing an event. Shouldn’t it be on interface type? Eventually...