Version
evolution-go v0.7.1 (Docker image evoapicloud/evolution-go:0.7.1).
Describe the bug
The event handler panics when processing a *events.Archive event (emitted by whatsmeow when a chat is archived/unarchived on any device of the account). It's a type-assertion failure — the event serialization layer seems to expect a map[string]interface{} but receives a *events.Archive:
[Client ERROR] Event handler panicked while handling a *events.Archive: interface conversion: interface {} is *events.Archive, not map[string]interface {}
panic({0x16a4b20?, 0x...?})
/usr/local/go/src/runtime/panic.go:783 +0x132
The same line repeats for every *events.Archive received.
Impact
The panic is usually recovered, but occasionally it brings the whole process down and Docker restarts the container. This is especially severe with CONNECT_ON_STARTUP=false: after the restart none of the instances reconnect automatically, so the entire fleet stays offline until a manual mass POST /instance/connect.
On a ~140-instance fleet we observed ~3 container restarts in 16h traced to this panic, plus hundreds of these panic log lines per day (peaks during business hours, when chats get archived the most).
To Reproduce
- Instance connected with webhook delivery enabled.
- Archive or unarchive a 1-1 chat — via
POST /chat/archive, from the phone, or arriving through app-state / history sync.
- whatsmeow emits
events.Archive → the handler panics with the type assertion above.
Expected behavior
events.Archive should be serialized/dispatched without panicking — and a panic in an event handler should never be able to crash the whole process (the recover should fully contain it).
Likely location
The event producer/serializer for webhook/AMQP/WebSocket output — something does value.(map[string]interface{}) on a value that is actually *events.Archive. The events.Archive struct (JID, Timestamp, Action, FromFullSync) probably needs an explicit mapping like the other event types have.
Environment
- Docker
evoapicloud/evolution-go:0.7.1
- Postgres backend (
evogo_auth / evogo_users)
- Webhook delivery enabled
- ~140 instances
Workaround we applied
On our side we stopped issuing POST /chat/archive (we archive only in our own DB), which removes the events we generate — but archives coming from the phone / history sync still trigger it. Happy to provide a fuller stack trace or more logs if useful.
Version
evolution-go v0.7.1(Docker imageevoapicloud/evolution-go:0.7.1).Describe the bug
The event handler panics when processing a
*events.Archiveevent (emitted by whatsmeow when a chat is archived/unarchived on any device of the account). It's a type-assertion failure — the event serialization layer seems to expect amap[string]interface{}but receives a*events.Archive:The same line repeats for every
*events.Archivereceived.Impact
The panic is usually recovered, but occasionally it brings the whole process down and Docker restarts the container. This is especially severe with
CONNECT_ON_STARTUP=false: after the restart none of the instances reconnect automatically, so the entire fleet stays offline until a manual massPOST /instance/connect.On a ~140-instance fleet we observed ~3 container restarts in 16h traced to this panic, plus hundreds of these panic log lines per day (peaks during business hours, when chats get archived the most).
To Reproduce
POST /chat/archive, from the phone, or arriving through app-state / history sync.events.Archive→ the handler panics with the type assertion above.Expected behavior
events.Archiveshould be serialized/dispatched without panicking — and a panic in an event handler should never be able to crash the whole process (the recover should fully contain it).Likely location
The event producer/serializer for webhook/AMQP/WebSocket output — something does
value.(map[string]interface{})on a value that is actually*events.Archive. Theevents.Archivestruct (JID,Timestamp,Action,FromFullSync) probably needs an explicit mapping like the other event types have.Environment
evoapicloud/evolution-go:0.7.1evogo_auth/evogo_users)Workaround we applied
On our side we stopped issuing
POST /chat/archive(we archive only in our own DB), which removes the events we generate — but archives coming from the phone / history sync still trigger it. Happy to provide a fuller stack trace or more logs if useful.