When a signal is happening it’s failing with following error
The scheduleEventID, activityID mapping exists in history
1 Like
I also debugged another one, observed that if a signal receive is timeout, then it’s failing with the error, we also noticed that when the same signal (the handler just updates the state) hits earlier at that we don’t have this problem.
Another workflow complete history:
Observe that the same signal (ServiceLifecycleUpdateSignal) is being sent multiple times, first few times it didn’t fail(id: 124), but after the signal with id: 150, which timed out with error schedule to start, it’s keeps on failing for the subsequent calls with pointing to different error (unable to map activity id for scheduled id 58),
Also observe that all other signal handlers are also failing with same error (id: 164)
What version of the SDK, service, and Web UI are you using? In the latest versions, I believe such errors should contain the whole panic stack trace.
Did you update the code while workflows were running?
we didn’t update the code, while workflows are running at all, the version is v0.26.0 (SDK/service/web UI)
Would you try upgrading to a latest supported version to see if you can reproduce the problem? The 0.26.0 was the pre-release version and is over 5 month old. There were numerous bug fixes in both service and SDKs since then.
It’s in production, we are planning migration, we are facing some serialisation issues in temporal v1, Even in our unit tests go protobuf are failing in Enum parsing(golang), when I look deeper the default go serialiser/deserialiser is not able to type cast it as google_protobuf, instead casting it as gogo_proto, where the enums are not registered, do you have any known solution for this ?
do you have any known solution for this ?
Please file an issue with the details about your problem and we will look into it.