Restoral of ActivationStateMachine events fails because not all event types have a no-argument constructor

[paddybyers]

Fatal Exception: java.lang.RuntimeException
java.lang.InstantiationException: java.lang.Class<u.a.a.d.d$l> has no zero argument constructor
io.ably.lib.push.ActivationStateMachine.getPersistedPendingEvents
Caused by java.lang.InstantiationException
java.lang.Class<u.a.a.d.d$l> has no zero argument constructor
java.lang.Class.newInstance (Class.java)
io.ably.lib.push.ActivationStateMachine.getPersistedPendingEvents (ActivationStateMachine.java:678)
io.ably.lib.push.ActivationStateMachine.loadPersisted (ActivationStateMachine.java:563)
io.ably.lib.push.ActivationStateMachine.<init> (ActivationStateMachine.java:557)
io.ably.lib.push.ActivationContext.getActivationStateMachine (ActivationContext.java:44)
io.ably.lib.push.Push.getStateMachine (Push.java:43)
io.ably.lib.push.Push.tryRequestRegistrationToken (Push.java:49)
io.ably.lib.rest.AblyRest.setAndroidContext (AblyRest.java:45)

ISTM that the following event types will not have a no-argument constructor, by virtue of having a declared constructor:

GettingDeviceRegistrationFailed
GettingPushDeviceDetailsFailed
UpdatingRegistrationFailed
DeregistrationFailed

[tcard]

This is related to #546. Those events are handled when in non-persisted states, ie. those waiting for a request's success or failure event.

[paddybyers]

But from the error it is attempting to restore one of these states. Are you saying that it shouldn't happen?

[tcard]

My point is that those events are intended to be handled while in states that aren't persisted anyway, so while this is a bug, those events probably shouldn't be persisted anyway (same with their 'success' counterparts) because they won't be handled properly.

Ie. fixing #546 should make this bug go away.

[paddybyers]

Is there a short-term fix (ie without persisting all states) whereby we don't persist these events?

[paddybyers]

@tcard ?

[tcard]

@paddybyers Sure, we can just check the number of arguments of the event class constructor just to avoid the exception. We need to, anyway, because we need to recover from such a "broken" persisted state even after we actually fix things so that it stops occurring, ideally by fixing #546.

Does the solution proposed in #546 sound good to you? I can give it a go tomorrow.

[paddybyers]

Does the solution proposed in #546 sound good to you?

yes, pls.

Thanks